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(57)Abstract: 

PROBLEM TO BE SOLVED: To quickly and surely perform access to a 
desired position of an AV stream. 

SOLUTION: The start point of a program and a picture in which the title of the 
program is displayed are respectively described in mark entry() and 
representative picture entry() in a clip constituting an AV stream. 
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CLAIMS 
[Claim(s)] 

[Claim 1] While generating ClipMark which consists of marks indicating the 
characteristic image extracted from inputted AV stream as management 
information for managing said AV stream A generation means to generate 
PlayListMark which consists of marks which point to the image which the user 
specified as arbitration out of the playback section corresponding to PlayList 
which defines the combination of the predetermined section in said AV stream, 
The information processor characterized by having a record means to record 
on a record medium by using said ClipMark and PlayListMark as the table 
which became independent respectively. 



[Claim 2] Said generation means is an information processor according to 

claim 1 characterized by generating said PlayList as a PlayList file while 

generating said ClipMark as a ClipMarklnformation file. 

[Claim 3] Said PlayListMark is an information processor according to claim 1 

characterized by being characterized by including further the mark which 

shows the Resume point when reproducing said PlayList. 

[Claim 4] The information processor according to claim 1 characterized by 

referring to said mark which constitutes ClipMark of said AV stream 

corresponding to the playback section of said PlayList when reproducing said 

PlayList. 

[Claim 5] Said mark of said PlayListMark is an information processor 
according to claim 1 characterized by including the identification information 
which shows the one playback section when it was specified on a 
presentation time stump and said AV stream data which constitute the 
salvage pathway of said PlayList. 

[Claim 6] Said mark which constitutes said ClipMark, or said mark which 
constitutes said PlayListMark is an information processor according to claim 1 
characterized by including the information which specifies the entry point of an 
elementary stream. 

[Claim 7] Said mark of said PlayListMark is an information processor 
according to claim 1 characterized by including the information on the type 
which includes the start point of the favorite scene specified by a user, or the 
Resume point of PlayList at least. 

[Claim 8] Said mark which constitutes said ClipMark, and said mark which 

constitutes said PlayListMark are an information processor according to claim 

1 characterized by what is expressed with the address of the relative source 

packet corresponding to the entry point of said AV stream. 

[Claim 9] Said mark which constitutes said ClipMark, and said mark which 

constitutes said PlayListMark are an information processor according to claim 

8 characterized by what is expressed with the 2nd address which is the 1st 

address of the relative source packet corresponding to the entry point of said 

AV stream, and the address of the offset from said 1st address. 

[Claim 10] Said 1st record means is an information processor according to 



claim 1 characterized by what said mark which constitutes said ClipMark, and 
said type detected by said type detection means are made to correspond, and 
is recorded, including further a type detection means detect the type of said 
characteristic image detected on the occasion of record by said 1st record 
means. 

[Claim 1 1] Said mark of said ClipMark is an information processor according 
to claim 1 characterized by including the scene as which the point changing 
[ scene ], the start point of commercials, the ending point of commercials, or 
the title was displayed. 

[Claim 12] While generating ClipMark which consists of marks indicating the 
characteristic image extracted from inputted AV stream as management 
information for managing said AV stream Out of the playback section 
corresponding to PlayList which defines the combination of the predetermined 
section in said AV stream The generation step which generates PlayListMark 
which consists of marks indicating the image which the user specified as 
arbitration, The information processing approach characterized by having the 
record control step which performs control at the time of recording on a record 
medium by using said ClipMark and PlayListMark as the table which became 
independent respectively. 

[Claim 13] While generating ClipMark which consists of marks indicating the 
characteristic image extracted from inputted AV stream as management 
information for managing said AV stream Out of the playback section 
corresponding to PlayList which defines the combination of the predetermined 
section in said AV stream The generation step which generates PlayListMark 
which consists of marks indicating the image which the user specified as 
arbitration, The record medium with which the program which the computer 
characterized by including the record control step which performs control at 
the time of recording on a record medium by using said ClipMark and 
PlayListMark as the table which became independent respectively can read is 
recorded. 

[Claim 14] While generating ClipMark which consists of marks indicating the 
characteristic image extracted from inputted AV stream as management 
information for managing said AV stream Out of the playback section 



corresponding to PlayList which defines the combination of the predetermined 
section in said AV stream The generation step which generates PlayListMark 
which consists of marks indicating the image which the user specified as 
arbitration, The program which makes a computer perform the record control 
step which performs control at the time of recording on a record medium by 
using said ClipMark and PlayListMark as the table which became independent 
respectively. 

[Claim 15] The management information for managing said AV stream 
containing ClipMark which consists of marks indicating the characteristic 
image extracted from AV stream, Out of the playback section corresponding 
to PlayList which defines the combination of the predetermined section in said 
AV stream The read-out means which reads PlayListMark which consists of 
marks indicating the image which the user specified as arbitration, A 
presentation means to show said management information by which reading 
appearance was carried out with said read-out means, and the information by 
said PlayLisMark, A reference means to refer to said ClipMark corresponding 
to said PlayList the user instructed playback to be from said information 
shown by said presentation means, The information processor characterized 
by including a playback means to reproduce said AV stream from the location 
corresponding to said ClipMark, including said ClipMark referred to by said 
reference means. 

[Claim 16] Said presentation means is an information processor according to 
claim 15 characterized by showing a user the list by the thumbnail image 
corresponding to said PlayLisMark. 

[Claim 17] Said mark which constitutes said ClipMark, and said mark which 
constitutes said PlayListMark are an information processor according to claim 
15 characterized by what is expressed with the address of the relative source 
packet corresponding to the entry point of said AV stream. 
[Claim 18] Said mark which constitutes said ClipMark, and said mark which 
constitutes said PlayListMark are an information processor according to claim 
17 characterized by what is expressed with the 2nd address which is the 1st 
address of the relative source packet corresponding to the entry point of said 
AV stream, and the address of the offset from said 1st address. 



< 1 

[Claim 19] Said mark of said ClipMark is an information processor according 
to claim 15 characterized by including the scene as which the point changing 
[ scene ], the start point of commercials, the ending point of commercials, or 
the title was displayed. 

[Claim 20] The management information for managing said AV stream 
containing ClipMark which consists of marks indicating the characteristic 
image extracted from AV stream, Out of the playback section corresponding 
to PlayList which defines the combination of the predetermined section in said 
AV stream The read-out control step which controls read-out of PlayListMark 
which consists of marks indicating the image which the user specified as 
arbitration, The presentation step which presents said management 
information by which read-out was controlled by processing of said read-out 
control step, and the information by said PlayLisMark, The reference step 
which refers to said ClipMark corresponding to said PlayList the user 
instructed playback to be from said information shown by processing of said 
presentation step, The information processing approach characterized by 
including the playback control step which controls playback of said AV stream 
from the location corresponding to said ClipMark including said ClipMark 
referred to by processing of said reference step. 
[Claim 21] The management information for managing said AV stream 
containing ClipMark which consists of marks indicating the characteristic 
image extracted from AV stream, Out of the playback section corresponding 
to PlayList which defines the combination of the predetermined section in said 
AV stream The read-out control step which controls read-out of PlayListMark 
which consists of marks indicating the image which the user specified as 
arbitration, The presentation step which presents said management 
information by which read-out was controlled by processing of said read-out 
control step, and the information by said PlayLisMark, The reference step 
which refers to said ClipMark corresponding to said PlayList the user 
instructed playback to be from said information shown by processing of said 
presentation step, The record medium with which the program which the 
computer characterized by including the playback control step which controls 
playback of said AV stream from the location corresponding to said ClipMark 



including said ClipMark referred to by processing of said reference step can 
read is recorded. 

[Claim 22] The management information for managing said AV stream 
containing ClipMark which consists of marks indicating the characteristic 
image extracted from AV stream, Out of the playback section corresponding 
to PlayList which defines the combination of the predetermined section in said 
AV stream The read-out control step which controls read-out of PlayListMark 
which consists of marks indicating the image which the user specified as 
arbitration, The presentation step which presents said management 
information by which read-out was controlled by processing of said read-out 
control step, and the information by said PlayLisMark, The reference step 
which refers to said ClipMark corresponding to said PlayList the user 
instructed playback to be from said information shown by processing of said 
presentation step, The program which makes a computer perform the 
playback control step which controls playback of said AV stream from the 
location corresponding to said ClipMark including said ClipMark referred to by 
processing of said reference step. 

[Claim 23] The record medium characterized by what is recorded as a table 
on which PlayListMark which consists of marks indicating the image which the 
user specified as arbitration became independent respectively out of the 
playback section corresponding to PlayList which defines the combination of 
the management information for managing said AV stream containing 
ClipMark which consists of marks indicating the characteristic image extracted 
from AV stream, and the predetermined section in said AV stream. 



DETAILED DESCRIPTION 



[Detailed Description of the Invention] 
[0001] 

[Field of the Invention] Especially this invention relates to a record medium at 



the information processor which enabled it to access promptly an information 
processor and an approach, a record medium, a program, and a list about a 
record medium in the location of a request of AV stream and an approach, a 
record medium, a program, and a list. 
[0002] 

[Description of the Prior Art] In recent years, record is possible and various 
kinds of optical disks are proposed as a dismountable disk mold medium from 
the record regenerative apparatus. The optical disk in which such record is 
possible is proposed as several G bytes of mass media, and its expectation 
as media which record AV (Audio Visual) signals, such as a video signal, is 
high. 

[0003] There are a bit stream from which the recording apparatus itself carries 
out picture compression of the audio video signal of an analog input, and it 
makes it by MPEG-2 method as the source (supply source) of digital AV 
signal recorded on the optical disk in which this record is possible, a bit 
stream of the MPEG 2 method directly obtained from the electric wave of 
digital television broadcast, etc. Generally, an MPEG 2 transport stream is 
used in digital television broadcast. A transport stream is a stream which the 
transport packet followed, and, as for a transport packet, for example, an 
MPEG 2 video stream and an MPEG1 audio stream are packet-ized. The data 
length of one transport packet is 188 bytes. If AV program of the transport 
stream received by digital television broadcast is recorded on an optical disk 
as it is with a recording apparatus, it is possible to record without completely 
degrading the quality of video or an audio. 
[0004] 

[Problem(s) to be Solved by the Invention] In order that a user may enable it 
to search the scene which is interested out of the transport stream currently 
recorded on the optical disk, for example, the point of a program pulling out 
the head etc., it is called for that random access playback can do a 
regenerative apparatus. 

[0005] Generally, the stream of MPEG 2 video encodes I picture at intervals of 
about 0.5 seconds, and the other picture is encoded as P picture or a B 
picture. Therefore, when carrying out random access and carrying out video 



recovery from the optical disk with which the stream of MPEG 2 video was 
recorded, I picture must be searched first. 

[0006] However, when carrying out random access to the transport stream 
currently recorded on the optical disk and carrying out video recovery to it 
conventionally, it was difficult to search the start byte of I picture efficiently, 
that is, it was difficult to have to analyze the syntax of the video stream which 
carried out reading appearance, to have to search the start byte of I picture, 
and for the search of I picture to take time amount, and to perform quick 
random access playback of a response from the random byte position of the 
transport stream on an optical disk, to the input from a user. 
[0007] This invention is made in view of such a situation, and enables it to 
perform promptly decision of the read-out location of the transport stream 
from a record medium, and decode initiation of a stream to directions of a 
random access rebirth of a user. 
[0008] 

[Means for Solving the Problem] While the 1st information processor of this 
invention generates ClipMark which consists of marks indicating the 
characteristic image extracted from inputted AV stream as management 
information for managing AV stream A generation means to generate 
PlayListMark which consists of marks which point to the image which the user 
specified as arbitration out of the playback section corresponding to PlayList 
which defines the combination of the predetermined section in AV stream, It is 
characterized by having a record means to record on a record medium by 
using ClipMark and PlayListMark as the table which became independent 
respectively. 

[0009] Said generation means can generate PlayList as a PlayList file while 
generating ClipMark as a ClipMarklnformation file. 
[0010] Said PlayListMark can include further the mark which shows the 
Resume point when reproducing PlayList. 

[001 1] When reproducing said PlayList, the mark which constitutes ClipMark 
of AV stream corresponding to the playback section of PlayList can be 
referred to. 

[0012] The mark of said PlayListMark can contain the identification 



information which shows the one playback section when it was specified on a 
presentation time stump and AV stream data which constitute the salvage 
pathway of PlayList. 

[0013] The mark which constitutes said ClipMark, or the mark which 
constitutes PlayListMark can include the information which specifies the entry 
point of an elementary stream. 

[0014] The mark of said PlayListMark can include the information on the type 
which includes the start point of the favorite scene specified by a user, or the 
Resume point of PlayList at least. 

[0015] The mark which constitutes said ClipMark, and the mark which 
constitutes PlayListMark can be expressed with the address of the relative 
source packet corresponding to the entry point of AV stream. 
[0016] The mark which constitutes said ClipMark, and the mark which 
constitutes PlayListMark can be expressed with the 2nd address which is the 
1st address of the relative source packet corresponding to the entry point of 
AV stream, and the address of the offset from the 1st address. 
[0017] Including further a type detection means to detect the type of the 
characteristic image detected on the occasion of record by said 1st record 
means, the 1st record means makes the mark which constitutes ClipMark, 
and the type detected by the type detection means correspond, and can be 
recorded. 

[0018] The mark of said ClipMark can contain the scene as which the point 
changing [ scene ], the start point of commercials, the ending point of 
commercials, or the title was displayed. 

[0019] While the 1st information processing approach of this invention 
generates ClipMark which consists of marks indicating the characteristic 
image extracted from inputted AV stream as management information for 
managing AV stream The generation step which generates PlayListMark 
which consists of marks which point to the image which the user specified as 
arbitration out of the playback section corresponding to PlayList which defines 
the combination of the predetermined section in AV stream, It is characterized 
by having the record control step which performs control at the time of 
recording on a record medium by using ClipMark and PlayListMark as the 



table which became independent respectively. 

[0020] While the program of the 1st record medium of this invention generates 
ClipMark which consists of marks indicating the characteristic image extracted 
from inputted AV stream as management information for managing AV stream 
The generation step which generates PlayListMark which consists of marks 
which point to the image which the user specified as arbitration out of the 
playback section corresponding to PlayList which defines the combination of 
the predetermined section in AV stream, It is characterized by including the 
record control step which performs control at the time of recording on a record 
medium by using ClipMark and PlayListMark as the table which became 
independent respectively. 

[0021] While the 1st program of this invention generates ClipMark which 
consists of marks indicating the characteristic image extracted from inputted 
AV stream as management information for managing AV stream The 
generation step which generates PlayListMark which consists of marks which 
point to the image which the user specified as arbitration out of the playback 
section corresponding to PlayList which defines the combination of the 
predetermined section in AV stream, A computer is made to perform the 
record control step which performs control at the time of recording on a record 
medium by using ClipMark and PlayListMark as the table which became 
independent respectively. 

[0022] Management information for the 2nd information processor of this 
invention to manage AV stream containing ClipMark which consists of marks 
indicating the characteristic image extracted from AV stream, The read-out 
means which reads PlayListMark which consists of marks indicating the 
image which the user specified as arbitration out of the playback section 
corresponding to PlayList which defines the combination of the predetermined 
section in AV stream, A presentation means to show the information by the 
management information and PlayLisMark by which reading appearance was 
carried out with the read-out means, A reference means to refer to ClipMark 
corresponding to PlayList the user instructed playback to be from the 
information shown by the presentation means, It is characterized by including 
a playback means to reproduce AV stream from the location corresponding to 



ClipMark, including ClipMark referred to by the reference means. 

[0023] Said presentation means can show a user the list by the thumbnail 

image corresponding to PlayLisMark. 

[0024] The mark which constitutes said ClipMark, and the mark which 

constitutes PlayListMark can be expressed with the address of the relative 

source packet corresponding to the entry point of AV stream. 

[0025] The mark which constitutes said ClipMark, and the mark which 

constitutes PlayListMark can be expressed with the 2nd address which is the 

1st address of the relative source packet corresponding to the entry point of 

AV stream, and the address of the offset from the 1st address. 

[0026] The mark of said ClipMark can contain the scene as which the point 

changing [ scene ], the start point of commercials, the ending point of 

commercials, or the title was displayed. 

[0027] Management information for the 2nd information processor of this 
invention to manage AV stream containing ClipMark which consists of marks 
indicating the characteristic image extracted from AV stream, Out of the 
playback section corresponding to PlayList which defines the combination of 
the predetermined section in AV stream The read-out control step which 
controls read-out of PlayListMark which consists of marks indicating the 
image which the user specified as arbitration, The presentation step which 
presents the information by the management information and PlayLisMark by 
which read-out was controlled by processing of a read-out control step, The 
reference step which refers to ClipMark corresponding to PlayList the user 
instructed playback to be from the information shown by processing of a 
presentation step, It is characterized by including the playback control step 
which controls playback of AV stream from the location corresponding to 
ClipMark including ClipMark referred to by processing of a reference step. 
[0028] Management information for the program of the 2nd record medium of 
this invention to manage AV stream containing ClipMark which consists of 
marks indicating the characteristic image extracted from AV stream, Out of 
the playback section corresponding to PlayList which defines the combination 
of the predetermined section in AV stream The read-out control step which 
controls read-out of PlayListMark which consists of marks indicating the 



image which the user specified as arbitration, The presentation step which 
presents the information by the management information and PlayLisMark by 
which read-out was controlled by processing of a read-out control step, The 
reference step which refers to ClipMark corresponding to PlayList the user 
instructed playback to be from the information shown by processing of a 
presentation step, It is characterized by including the playback control step 
which controls playback of AV stream from the location corresponding to 
ClipMark including ClipMark referred to by processing of a reference step. 
[0029] Management information for the program of this invention to manage 
AV stream containing ClipMark which consists of marks indicating the 
characteristic image extracted from AV stream, Out of the playback section 
corresponding to PlayList which defines the combination of the predetermined 
section in AV stream The read-out control step which controls read-out of 
PlayListMark which consists of marks indicating the image which the user 
specified as arbitration, The presentation step which presents the information 
by the management information and PlayLisMark by which read-out was 
controlled by processing of a read-out control step, The reference step which 
refers to ClipMark corresponding to PlayList the user instructed playback to 
be from the information shown by processing of a presentation step, A 
computer is made to perform the playback control step which controls 
playback of AV stream from the location corresponding to ClipMark including 
ClipMark referred to by processing of a reference step. 
[0030] It is characterized by what is recorded as a table on which 
PlayListMark which consists of marks indicating the image which the user 
specified as arbitration became independent respectively out of the playback 
section corresponding to PlayList which defines the combination of the 
management information for managing AV stream which contains in the 3rd 
record medium of this invention ClipMark which consists of marks indicating 
the characteristic image extracted from AV stream, and the predetermined 
section in AV stream. 

[0031] It sets to a program at the 1st information processor of this invention 
and an approach, and a list. While generating ClipMark which consists of 
marks indicating the characteristic image extracted from inputted AV stream 



as management information for managing AV stream Out of the playback 
section corresponding to PlayList which defines the combination of the 
predetermined section in AV stream PlayListMark which consists of marks 
indicating the image which the user specified as arbitration is generated, and 
it is recorded on a record medium as a table on which ClipMark and 
PlayListMark became independent respectively. 

[0032] In the 2nd information processor of this invention and an approach, 
and a list, a program The management information for managing AV stream 
containing ClipMark which consists of marks indicating the characteristic 
image extracted from AV stream, Out of the playback section corresponding 
to PlayList which defines the combination of the predetermined section in AV 
stream Reading appearance of the PlayListMark which consists of marks 
indicating the image which the user specified as arbitration is carried out. The 
management information by which reading appearance was carried out, and 
the information by PlayLisMark are shown. From the shown information, 
ClipMark corresponding to PlayList the user instructed playback to be is 
referred to, and AV stream is reproduced from the location corresponding to 
ClipMark including ClipMark referred to. 
[0033] 

[Embodiment of the Invention] Below, the gestalt of operation of this invention 
is explained with reference to a drawing. Drawing 1 is drawing showing the 
example of an internal configuration of the record regenerative apparatus 1 
which applied this invention. First, the configuration of the Records 
Department 2 which performs actuation which records the signal inputted from 
the outside on a record medium is explained. The record regenerative 
apparatus 1 is considered as the configuration which can input analog data or 
digital data and can be recorded. 

[0034] The video signal of an analog is inputted into a terminal 11, and the 
audio signal of an analog is inputted into a terminal 12, respectively. The 
video signal inputted into the terminal 11 is outputted to the analysis section 
14 and the AV encoder 15, respectively. The audio signal inputted into the 
terminal 12 is outputted to the analysis section 14 and the AV encoder 15. 
The analysis section 14 extracts the focus, such as a scene change, from the 



inputted video signal and an audio signal. 

[0035] The AV encoder 15 encodes the video signal and audio signal which 
were inputted, respectively, and outputs system information (S), such as a 
coding video stream (V), a coding audio stream (A), and AV synchronization, 
to a multiplexer 16. 

[0036] A coding video stream is a video stream encoded for example, by 
MPEG(Moving Picture Expert Group) 2 method, and coding audio streams 
are the audio stream encoded for example, by MPEG1 method, an audio 
stream encoded by DORUBI AC3 method (trademark). A multiplexer 16 
multiplexes the stream of the inputted video and an audio based on input 
system information, and outputs it to the multiplexing stream analysis section 
18 and sow spa KETTAIZA 19 through a switch 17. 
[0037] Multiplexing streams are for example, an MPEG 2 transport stream 
and an MPEG 2 program stream. Sow spa KETTAIZA 19 encodes the 
inputted multiplexing stream to AV stream which consists of source packets 
according to an application format of the record medium 100 on which the 
stream is made to record. Addition and modulation processing of an ECC sign 
are performed in the ECC (error correction) coding section 20 and the 
modulation section 21 , and AV stream is outputted to the write-in section 22. 
The write-in section 22 writes AV stream file in a record medium 100 based 
on the control signal outputted from a control section 23 (it records). 
[0038] Transport streams, such as digital television broadcast inputted from a 
digital interface or a digital television tuner, are inputted into a terminal 13. 
They are the method which records those with two kind, and them on 
transparent at the recording method of a transport stream inputted into the 
terminal 13, and the method recorded after carrying out re-encoding for the 
objects, such as lowering a record bit rate. The directions information on a 
recording method is inputted into a control section 23 from the terminal 24 as 
a user interface. 

[0039] When recording an input transport stream on transparent, the transport 
stream inputted into the terminal 13 is outputted to the multiplexing stream 
analysis section 18 and sow spa KETTAIZA 19 through a switch 17. Since 
processing until AV stream is recorded on the record medium 100 after this is 



the same processing as the case where the above-mentioned input audio 
signal and above-mentioned video signal of an analog are encoded and 
recorded, the explanation is omitted. 

[0040] When recording after re-encoding an input transport stream, the 
transport stream inputted into the terminal 13 is inputted into a demultiplexer 
26. A demultiplexer 26 performs demultiplex processing to the inputted 
transport stream, and extracts a video stream (V), an audio stream (A), and 
system information (S). 

[0041] A video stream is outputted to the AV decoder 27 among the streams 
(information) extracted by the demultiplexer 26, and an audio stream and 
system information are outputted to a multiplexer 16, respectively. The AV 
decoder 27 decodes the inputted video stream, and outputs the playback 
video signal to the AV encoder 15. The AV encoder 15 encodes an input 
video signal, and outputs a coding video stream (V) to a multiplexer 16. 
[0042] On the other hand, based on input system information, the audio 
stream which was outputted from the demultiplexer 26 and inputted into the 
multiplexer 16, system information, and the video stream outputted from the 
AV encoder 15 are multiplexed, and is outputted to the multiplexing stream 
analysis section 18 and source packet TAIZA 19 through a switch 17 as a 
multiplexing stream. Since processing until AV stream is recorded on the 
record medium 100 after this is the same processing as the case where the 
above-mentioned input audio signal and above-mentioned video signal of an 
analog are encoded and recorded, the explanation is omitted. 
[0043] The record regenerative apparatus 1 of the gestalt of this operation 
also records the application database information that the file is explained 
while recording the file of AV stream on a record medium 100. Application 
database information is created by the control section 23. The input to a 
control section 23 is the description information on the dynamic image from 
the analysis section 14, the description information on AV stream from the 
multiplexing stream analysis section 18, and the directions information from a 
user that it is inputted from a terminal 24. 

[0044] The description information on the dynamic image supplied from the 
analysis section 14 is generated by the analysis section 14 when the AV 



encoder 15 encodes a video signal. The analysis section 14 analyzes the 
content of an input video signal and the audio signal, and generates the 
information related to the characteristic image in an input dynamic-image 
signal (clip mark). This is the directions information on the image of the 
characteristic points marking [ clip ], such as start point [ of the program in an 
input video signal ], and changing [ scene ] point and starting point [ of CM 
commercials ] - and a point, a title, and a telop, and the thumbnail of the 
image is also contained in it. Furthermore, the stereo of an audio signal, and 
the switching point of a monophonic recording and the information on the 
silent section etc. are also included. 

[0045] The directions information on these images is inputted into a 
multiplexer 16 through a control section 23. A multiplexer 16 returns the 
information for specifying the coding picture on AV stream to a control section 
23, when multiplexing the coding picture specified as a clip mark from a 
control section 23. Specifically, this information is the address information on 
PTS (presentation time stump) of a picture, or AV stream of that coding 
picture. A control section 23 associates and memorizes the information for 
specifying the class and its coding picture of a characteristic image on AV 
stream. 

[0046] The description information on AV stream from the multiplexing stream 
analysis section 18 is the information related to the encoded information of AV 
stream recorded, and is generated by the analysis section 18. For example, 
the changing point information on the time stump of I picture in AV stream, 
address information, the break point information on a system time clock, the 
coding parameter of AV stream, and the coding parameter in AV stream etc. 
is included. Moreover, when recording the transport stream inputted from a 
terminal 13 on transparent, the multiplexing stream analysis section 18 
detects the image of the above-mentioned clip mark out of an input transport 
stream, and generates the information for specifying the picture specified by 
the class and clip mark. 

[0047] The directions information of the user from a terminal 24 is the 
character alphabetic character explaining the assignment information on the 
playback section specified by the user in AV stream, and the content of the 



playback section, the bookmark which a user sets to a favorite scene, the 
information on a resume point, etc. 

[0048] A control section 23 creates the management information (info.dvr) of 
the database (Clip) of AV stream, the database of what (PlayList) carried out 
grouping of the playback section (Playltem) of AV stream, and the content of 
record of a record medium 100, and the information on a thumbnail image 
based on the above-mentioned input. Like AV stream, the application 
database information which consists of such information is processed in the 
ECC coding section 20 and the modulation section 21, and is inputted into the 
write-in section 22. The write-in section 22 records a database file on a record 
medium 100 based on the control signal outputted from a control section 23. 
[0049] The detail about the application database information mentioned above 
is mentioned later. 

[0050] Thus, when application database information is reproduced by the 
playback section 3 with AV stream file (file of image data and voice data) 
recorded on the record medium 100, a control section 23 directs to read 
application database information from a record medium 100 to the read-out 
section 28 first. And the read-out section 28 reads application database 
information from a record medium 100, and the application database 
information is inputted into a control section 23 through a recovery and error 
correction processing of the recovery section 29 and the ECC decode section 
30. 

[0051] A control section 23 outputs the list of PlayList currently recorded on 
the record medium 100 to the user interface of a terminal 24 based on 
application database information. A user chooses PlayList to reproduce from 
the list of PlayList, and the information about PlayList which had playback 
specified is inputted into a control section 23. A control section 23 directs 
read-out of AV stream file required for playback of the PlayList in the read-out 
section 28. The read-out section 28 reads AV stream which corresponds from 
a record medium 100 according to the directions, and outputs it to the 
recovery section 29. It gets over by performing predetermined processing, 
and AV stream inputted into the recovery section 29 is further outputted 
source DEPAKETTAIZA 31 through processing of the ECC decode section 30. 



[0052] Reading appearance of source DEPAKETTAIZA 31 is carried out from 
a record medium 100, and it changes AV stream of an application format to 
which predetermined processing was performed into the stream which can 
process a demultiplexer 26. A demultiplexer 26 outputs system information 
(S), such as a video stream (V) which constitutes the playback section 
(Playltem) of AV stream specified by the control section 23, an audio stream 
(A), and AV synchronization, to the AV decoder 27. The AV decoder 27 
decodes a video stream and an audio stream, and outputs a playback video 
signal and a playback audio signal from the terminal 32 and terminal 33 which 
correspond, respectively. 

[0053] Moreover, when the information which directs random access playback 
and special playback is inputted from the terminal 24 as a user interface, 
based on the content of the database (Clip) of AV stream, a control section 23 
determines the read-out location of AV stream from a storage 100, and directs 
read-out of the AV stream in the read-out section 28. For example, when 
reproducing PlayList chosen by the user from predetermined time of day, as a 
control section 23 reads the data with the time stump nearest to the specified 
time of day from I picture, it is read, and it is directed in the section 28. 
[0054] moreover, out of the point of the program currently stored in ClipMark 
in Clip Information pulling out the head, or the point changing [ scene ] When 
a clip mark with a user is chosen (for example, this actuation) The thumbnail 
image list of the point of a program pulling out the head or points changing 
[ scene ] currently stored in ClipMark is displayed on a user interface. Based 
on the content of Clip Information, a user determines the read-out location of 
AV stream from a record medium 100, reads read-out of the AV stream, and 
directs the control section 23 performed by choosing a certain image from the 
inside to the section 28. That is, it reads so that the data from I picture in the 
address nearest to the address on AV stream in which the image which the 
user chose is stored may be read, and it directs to the section 28. AV data 
which the read-out section 28 reads data from the specified address, and the 
data by which reading appearance was carried out are inputted into a 
demultiplexer 26 through processing of the recovery section 29, the ECC 
decode section 30, and source DEPAKETTAIZA 31, are decoded by the AV 



decoder 27, and are shown in the address of the picture of a marking point 
are reproduced. 

[0055] Moreover, when high-speed playback (Fast-forward playback) is 
directed by the user, as sequential continuation is carried out and a control 
section 23 reads l-picture data in AV stream based on the database (Clip) of 
AV stream, it is read, and it is directed in the section 28. 
[0056] The read-out section 28 reads the data of AV stream from the specified 
random access point, and the data by which reading appearance was carried 
out are reproduced through processing of latter each part. 
[0057] Next, a user explains the case where AV stream currently recorded on 
the record medium 100 is edited. When a user wants to specify the playback 
section of AV stream currently recorded on the record medium 100, and to 
create new salvage pathway, For example, from the song program of 
Program A, reproduce Singer's A part and it continues after that. The 
information on the start point (Inn point) of the playback section and an ending 
point (out point) is inputted into a control section 23 from the terminal 24 as a 
user interface to create the salvage pathway of wanting to reproduce the part 
of the singer A of the song program of Program B. A control section 23 
creates the database of what (PlayList) carried out grouping of the playback 
section (Playltem) of AV stream. 

[0058] When a user wants to eliminate a part of AV stream currently recorded 
on the record medium 100, the information on the Inn point of the elimination 
section and an out point is inputted into a control section 23 from the terminal 
24 as a user interface. A control section 23 changes the database of PlayList 
so that only required AV stream part may be referred to. Moreover, it directs in 
the write-in section 22 so that the unnecessary stream part of AV stream may 
be eliminated. 

[0059] It is the case where a user wants to specify the playback section of AV 
stream currently recorded on the record medium 100, and to create new 
salvage pathway, and the case where he wants to connect each playback 
section seamlessly is explained. In such a case, a control section 23 creates 
the database of what (PlayList) carried out grouping of the playback section 
(Playltem) of AV stream, and performs near a node partial re-encoding and 



re-multiplexing of the playback section of a video stream further. 
[0060] First, the information on the picture of the Inn point of the playback 
section and the information on the picture of an out point are inputted into a 
control section 23 from a terminal 24. A control section 23 directs read-out of 
data required in order to reproduce the Inn point side picture and the picture 
by the side of an out point in the read-out section 28. And the read-out section 
28 reads data from a record medium 100, and the data is outputted to a 
demultiplexer 26 through the recovery section 29, the ECC decode section 30, 
and source DEPAKETTAIZA 31. 

[0061] A control section 23 analyzes the data inputted into the demultiplexer 
26, determines a re-multiplex system as the re-encoding approach 
(modification of picture_coding_type, assignment of the re-encoded amount of 
coding bits) of a video stream, and supplies the method to the AV encoder 15 
and a multiplexer 16. 

[0062] Next, a demultiplexer 26 divides the inputted stream into a video 
stream (V), an audio stream (A), and system information (S). A video stream 
has the data inputted into the AV decoder 27, and data inputted into a 
multiplexer 16. It is data required in order to re-encode the former data, and 
this is decoded by the AV decoder 27, and the decoded picture is re-encoded 
with the AV encoder 15, and is made into a video stream. The latter data are 
data copied from the stream of an original copy without carrying out re- 
encoding. About an audio stream and system information, it is directly 
inputted into a multiplexer 16. 

[0063] Based on the information inputted from the control section 23, a 
multiplexer 16 multiplexes an input stream and outputs a multiplexing stream. 
A multiplexing stream is processed in the ECC coding section 20 and the 
modulation section 21, and is inputted into the write-in section 22. The write-in 
section 22 records AV stream on a record medium 100 based on the control 
signal supplied from a control section 23. 

[0064] Explanation about actuation of the playback and edit based on 
application database information and its information is given to below. 
Drawing 2 is drawing explaining the structure of an application format. An 
application format has two layers, PlayList and Clip, for management of AV 



stream. Volume Information carries out management of all Clip(s) and 
PlayList(s) in a disk. Here, the pair of one AV stream and its attached 
information is considered to be one object, and it is called Clip. AV stream file 
calls Clip AV stream file, and the attached information is called Clip 
Information file. 

[0065] One Clip AV stream file stores the data which have arranged the 
MPEG 2 transport stream in the structure in which it is specified by application 
format. Generally, although a file is treated as a sequence of bytes, the 
contents of Clip AV stream file are developed on a time-axis, and the entry 
point in Clip (I picture) is mainly specified in a hourly base. When the time 
stump of the access point to predetermined Clip is given, Clip Information file 
is useful in order to find the address information which should start read-out of 
data in Clip AV stream file. 

[0066] PlayList is explained with reference to drawing 3 . PlayList chooses 
from Clip(s) the playback section which a user wants to see, and it is prepared 
in order to enable it to edit it simply. One PlayList is the meeting of the 
playback section in Clip. The one playback section in predetermined Clip is 
called Playltem, and it is expressed with the pair of the Inn point on a time- 
axis (IN), and an out point (OUT). Therefore, PlayList is constituted when two 
or more Playltem(s) gather. 

[0067] There are two types of PlayList(s). One is Real PlayList and another is 
Virtual PlayList. Real PlayList is sharing the stream part of Clip which it is 
referring to. That is, when Real PlayList occupies in a disk the data volume 
equivalent to the stream part of Clip which is referring to it and Real PlayList is 
eliminated, data are eliminated also for the stream part of Clip which it is 
referring to. 

[0068] Virtual PlayList is not sharing the data of Clip. Therefore, even if Virtual 
PlayList is changed or eliminated, by the content of Clip, change does not 
arise at all. 

[0069] Next, edit of Real PlayList is explained. Drawing 4 (A) is drawing about 
the creation (create: creation) of Real PlayList, and when AV stream is 
recorded as new Clip, it is actuation in which Real PlayList which refers to the 
whole Clip is newly created. 



[0070] Drawing 4 (B) is drawing about the divide (divide: division) of Real 
PlayList, and is actuation in which Real PlayList is divided at a point [ **** ] 
and divided into two Real PlayList. when two programs are managed in one 
clip managed by one PlayList, a user wants to do the actuation of this division 
again registration (record) as each program - like - it is sometimes carried 
out. There is nothing for which the content of Clip is changed by this actuation 
(the Clip itself is divided). 

[0071] Drawing 4 (C) is drawing about the combined harvester and thresher 
(combine: association) of Real PlayList, and is actuation which combines two 
Real PlayList and is set to one new Real PlayList. a user wants, as for the 
actuation of this association, to reregister two programs as one program - like 
- it is sometimes carried out. There is nothing for which Clip is changed by 
this actuation (the Clip itself is set to one). 

[0072] Drawing 5 (A) is drawing about deletion (delete: deletion) of whole Real 
PlayList, and when actuation which eliminates whole predetermined Real 
PlayList is carried out, the stream part to which Clip which deleted Real 
PlayList refers to corresponds is also deleted. 

[0073] Drawing 5 (B) is drawing about partial deletion of Real PlayList, and 
when a part [ **** / Real PlayList ] is deleted, it is changed so that 
corresponding Playltem may refer to only the stream part of required Clip. 
And the stream part to which Clip corresponds is deleted. 
[0074] Drawing 5 (C) is drawing about minimization (Minimize: minimization) 
of Real PlayList, and is actuation of referring to only the stream part of Clip 
required for Virtual PlayList for Playltem corresponding to Real PlayList. 
Virtual PlayList The stream part to which it takes and unnecessary Clip 
corresponds is deleted. 

[0075] Real PlayList is changed by actuation which was mentioned above, 
when the stream part of Clip which the Real PlayList refers to is deleted, 
Virtual PlayList which is using the deleted Clip may exist, and a problem may 
arise by deleted Clip in the Virtual PlayList. 

[0076] As opposed to actuation of [ so that such a thing may not arise ] 
deletion to a user "If Virtual PlayList which is referring to the stream part of 
Clip which the Real PlayList is referring to exists and the Real PlayList is 



eliminated although the Virtual PlayList will also be eliminated, is still it good? 
processing of the deletion with directions of a user after urging a check 
(warning) by displaying the message " etc. - activation - or it cancels. Or 
actuation of minimization is made to be performed instead of deleting Virtual 
PlayList to Real PlayList. 

[0077] Next, the actuation to Virtual PlayList is explained. The content of Clip 
is not changed even if actuation is performed to Virtual PlayList. Drawing. 6 is 
an assemble (Assemble). Edit (IN-OUT edit) It is related drawing and is 
actuation of making Playltem of the playback section for which it asked when 
the user wanted to see, and creating Virtual PlayList. The seamless 
connection between Playltem(s) is supported by the application format (after- 
mentioned). 

[0078] As shown in drawing 6 (A), two Real PlayList 1 and 2, When Clip 1 and 
2 corresponding to each RealPlayList exists A user directs the predetermined 
section in Real PlayListl (section-laylteml to In1 thru/or Out1) as the 
playback section, and as the section reproduced continuously When the 
predetermined section in Real PlayList2 (section-layltem2 to In2 thru/or Out2) 
is directed as the playback section, As shown in drawing 6 (B), one Virtual 
PlayList which consists of Playlteml and Playltem2 is created. 
[0079] Next, Virtual PlayList A reorganization collection (Re-editing) is 
explained. A reorganization collection has insertion (insert) of modification of 
the Inn point in Virtual PlayList, and an out point, and new Playltem to Virtual 
PlayList, an addition (append), deletion of Playltem in Virtual PlayList, etc. 
Moreover, Virtual PlayList itself can also be deleted. 
[0080] Drawing 7 is drawing about postrecording (Audio dubbing (post 
recording)) of the audio to Virtual PlayList, and is actuation which registers 
postrecording of the audio to Virtual PlayList as subpass. Postrecording of this 
audio is supported by the application format. An additional audio stream is 
added to AV stream of the main path of Virtual PlayList as subpass. 
[0081] As actuation common to Real PlayList and Virtual PlayList, there is 
modification (Moving) of the playback sequence of PlayList as shown in 
drawing 8 . This actuation is modification of the playback sequence of PlayList 
in the inside of a disk (volume), and is supported by Table Of PlayList (with 



reference to drawing 20 etc., it mentions later) defined in an application format. 
As [ change / by this actuation / the content of Clip ] 
[0082] Next, a mark (Mark) is explained. The mark is prepared in order to 
specify the highlights in Clip and PlayList, and characteristic time amount, as 
shown in drawing 9 . The mark added to Clip is called ClipMark (clip mark). 
Specify the characteristic scene resulting from the content of the AV stream, 
for example, ClipMark is a head broth point, a point changing [ scene ], etc. of 
a program. ClipMark is generated by the analysis section 14 of drawing 1 . 
When reproducing PlayList, it can be used with reference to the mark of Clip 
which the PlayList refers to. 

[0083] The mark added to PlayList is called PlayListMark (play list mark). Are 
mainly set by the user, for example, PlayListMark(s) are a bookmark, a 
resume point, etc. Setting a mark to Clip or PlayList is performed by adding 
the time stump in which the time of day of a mark is shown to a mark list. 
Moreover, deleting a mark is removing the time stump of the mark out of a 
mark list. Therefore, as for AV stream, a change of what is not made by 
setting out or deletion of a mark, either. 

[0084] You may make it specify the picture which ClipMark refers to with the 
address base in the inside of AV stream as another format of ClipMark. 
Setting a mark to Clip is performed by adding the information on the address 
base which shows the picture of a marking point to a mark list. Moreover, 
deleting a mark is removing the information on the address base which shows 
the picture of the marking point out of a mark list. Therefore, as for AV stream, 
a change of what is not made by setting out or deletion of a mark, either. 
[0085] Next, a thumbnail is explained. A thumbnail is a still picture added to 
Volume, PlayList, and Clip. There are two classes of thumbnails and one is a 
thumbnail as representation drawing showing the content. This is used in the 
menu screen for choosing the thing a user mainly wants to operate and look 
at cursor (un-illustrating) etc. Another is an image showing the scene which 
the mark has pointed out. 

[0086] Volume and each Playlist need to enable it to have representation 
drawing. The representation drawing of Volume assumes being used when 
displaying the still picture showing the content of the disk first, when a disk (a 



record medium 100 presupposes that it is a disk-like thing, and is suitably 
described to be a disk a record medium 100 and the following) is set to the 
predetermined location of the record regenerative apparatus 1. The 
representation drawing of Playlist assumes being used as a still picture for 
expressing the content of Playlist in the menu screen which chooses Playlist. 
[0087] Although it is possible as representation drawing of Playlist to make the 
image of the beginning of Playlist into a thumbnail (representation drawing), it 
is not not necessarily the image optimal when the image of the head of the 
playback time of day 0 expresses the content. Then, a user enables it to set 
up the image of arbitration as a thumbnail of Playlist. Two kinds of thumbnails, 
the thumbnail as representation drawing which expresses Volume above, and 
the thumbnail as representation drawing showing PlayList, are called a menu 
thumbnail. Since a menu thumbnail is displayed frequently, reading 
appearance of it needs to be carried out to a high speed from a disk. For this 
reason, it is efficient to store all menu thumbnails in one file. It is not 
necessary to be necessarily the picture extracted from the animation in 
volume, and as shown in drawing 10 , a menu thumbnail may be taken from a 
personal computer or a digital still camera, and a ********** image is sufficient 
as it. 

[0088] It can be necessary to strike two or more marks, and in order to know 
the content of the mark location, it is necessary to enable it to see the image 
of a marking point easily to Clip and Playlist on the other hand. The picture 
showing such a marking point is called a mark thumbnail (Mark Thumbnails). 
Therefore, the image which becomes the origin of a mark thumbnail becomes 
main [ what extracted the image of a marking point ] from the image captured 
from the outside. 

[0089] Drawing 1 1 is the mark attached to PlayList, and drawing showing the 
relation of the mark thumbnail, and drawing 12 is the mark attached to Clip, 
and drawing showing the relation of the mark thumbnail. Since a mark 
thumbnail is used by the sub menu etc. when the detail of Playlist is 
expressed unlike a menu thumbnail, what reading appearance is carried out 
in the short access time is not required. Therefore, it does not become a 
problem, even if it takes time amount somewhat because the record 



regenerative apparatus 1 reads an aperture and a part of its file for a file 
whenever a thumbnail is heeded. 

[0090] Moreover, in order to reduce the number of files which exists in volume, 
all mark thumbnails are good to store in one file. Although Playlist can have 
one-menu thumbnail and two or more mark thumbnails, since Clip does not 
have the need that a direct user chooses (it usually specifies via Playlist), it 
does not need to prepare a menu thumbnail. 

[0091] Drawing 13 is drawing having shown the relation of the menu 
thumbnail at the time of taking having mentioned above into consideration, a 
mark thumbnail, PlayList, and Clip. The menu thumbnail prepared in the menu 
thumbnail file for every PlayList is filed. The volume thumbnail representing 
the content of the data currently recorded on the disk is contained in the menu 
thumbnail file. The thumbnail by which the mark thumbnail file was created for 
every Clip with every PlayList is filed. 

[0092] Next, CPI (Characteristic Point Information) is explained. CPI is data 
contained in a Clip information file, and when the time stump of the access 
point to Clip is given, it is mainly used in order to find the data address which 
should start read-out of data in Clip AV stream file. Two kinds of CPI(s) are 
used with the gestalt of this operation. One is EP_map and another is 
TU_map. 

[0093] EP_map is the list of entry point (EP) data, and it is extracted from an 
elementary stream and a transport stream. This has the address information 
for finding the location of the entry point which should start decoding in AV 
stream. One EP data consists of pairs of the data address in a presentation 
time stump (PTS) and AV stream of the access unit corresponding to the PTS. 
[0094] EP_map is mainly used for two objects. It is used in order to find the 
data address in AV stream of the access unit referred to [ 1st ] with a 
presentation time stump in PlayList. It is used for the 2nd for first forward 
playback or first reverse playback. When the record regenerative apparatus 1 
records an input AV stream and the syntax of the stream can be analyzed, 
EP_map is created and it is recorded on a disk. 

[0095] TU_map has the list of the time unit (TU) data based on the arrival time 
of the transport packet inputted through a digital interface. This gives the 
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contained in a Clip information file, and when the time stump of the access 
point to Clip is given, it is mainly used in order to find the data address which 
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relation between the time amount of the arrival time base, and the data 
address in AV stream. When the record regenerative apparatus 1 records an 
input AV stream and the syntax of the stream cannot be analyzed, TlLmap is 
created and it is recorded on a disk. 

[0096] STCInfo stores the break point information on STC in AV stream file 
which is storing the MPEG 2 transport stream. Temporarily, when AV stream 
has the break point of STC, PTS of the same value may appear in the AV 
stream file. Therefore, when pointing out the predetermined time of day on AV 
stream with the PTS base, just PTS of an access point is inadequate in order 
to specify the point. 

[0097] Furthermore, the index of the STC section [ **** ] containing the PTS is 
required. In this format, STC-sequence, a call, and its index are described to 
be STC-sequence-id for the STC section [ **** ]. The information on STC- 
sequence is defined by STCInfo of Clip Information file. STC-sequence-id is 
an option in AV stream file which uses it by AV stream file with EPjnap, and 
has TU_map. 

[0098] A program is the meeting of an elementary stream and shares only one 
system time base for synchronous playback of these streams. What the 
content of the AV stream understands in advance of decoding of AV stream 
for a regenerative apparatus is useful. For example, they are information, 
such as a value of PID of the transport packet which transmits the elementary 
stream of video or an audio, video, and a component class of audio, (for 
example, audio streams of the video of HDTV, and MPEG-2 AAC etc.). 
[0099] This information is useful although the menu screen which explains to 
a user the content of PlayList which refers to AV stream is created, and it is 
useful in order to set AV decoder of a regenerative apparatus, and the initial 
state of a demultiplexer in advance of decoding of AV stream. For this reason, 
Clip Information file has Programlnfo for explaining the content of the program. 
[0100] As for AV stream file which is storing the MPEG 2 transport stream, the 
content of a program may change in a file. For example, it is that PID of the 
transport packet which transmits a video elementary stream changes, or the 
component class of video stream changes from SDTV to HDTV etc. 
[0101] Programlnfo stores the information on the changing point of the 



content of a program in the inside of AV stream file. In AV stream file, the 
content of a program defined in this format calls the fixed section Program- 
sequence. Program-sequence is an option in AV stream file which uses it by 
AV stream file with EP_map, and has TUjnap. 

[0102] The gestalt of this operation defines the stream format (SESF) of self 
encoding. SESF is used when encoding to an MPEG 2 transport stream, after 
decoding the object which encodes an analog input signal, and a digital input 
signal (for example, DV). 

[0103] SESF defines a coding limit of the elementary stream about an MPEG- 
2 transport stream and AV stream. When the record regenerative apparatus 1 
encodes and records a SESF stream, EP_map is created and it is recorded 
on a disk. 

[0104] Either of the methods shown below is used and the stream of digital 
broadcasting is recorded on a record medium 100. First, transformer coding of 
the stream of digital broadcasting is carried out at a SESF stream. In this case, 
the recorded stream must be based on SESF. In this case, EP_map must be 
created and it must be recorded on a disk. 

[0105] Or transformer coding is carried out at a new elementary stream, and 
the elementary stream which constitutes a digital-broadcasting stream is re- 
multiplexed to the new transport stream based on the stream format which the 
normalization organization of the digital-broadcasting stream defines. In this 
case, EP_map must be created and it must be recorded on a disk. 
[0106] For example, an input stream is an MPEG-2 transport stream of ISDB 
(specification name of digital BS broadcast of Japan) conformity, and suppose 
that it contains a HDTV video stream and a MPEG AAC audio stream. 
Transformer coding of the HDTV video stream is carried out at a SDTV video 
stream, and the SDTV video stream and AAC audio stream of an original 
copy are re-multiplexed to TS. Both the transport streams recorded as a 
SDTV stream must be based on an ISDB format. 
[0107] The stream of digital broadcasting is the case (it records without 
changing any input transport streams) where an input transport stream is 
recorded on transparent as other methods at the time of being recorded on a 
record medium 100, and EP_map is then created and it is recorded on a disk. 



[0108] Or it is the case (it records without changing any input transport 
streams) where an input transport stream is recorded on transparent, and 
TU_map is then created and it is recorded on a disk. 
[0109] Next, a directory and a file are explained. Hereafter, the record 
regenerative apparatus 1 is suitably described to be DVR (Digital Video 
Recording). Drawing 14 is drawing showing an example of the directory 
structure on a disk. Directories required on the disk of DVR are a root 
directory including a "DVR" directory, a "PLAYLIST" directory, a "CLIPINF" 
directory, and a "DVR" directory including an "M2TS" directory and "DATA" 
directory, as shown in drawing 14 . Although directories other than these may 
be made to be created under a root directory, they presuppose that it is 
ignored in an application format of the gestalt of this operation. 
[01 10] All the files and directories that are specified by DVR application format 
in the bottom of a "DVR" directory are stored. A "DVR" directory includes four 
directories. On the bottom of a "PLAYLIST" directory, the database file of Real 
PlayList and Virtual PlayList is put. This directory exists, even if one does not 
have PlayList. 

[01 1 1] The database of Clip is put on the bottom of a "CLIPINF" directory. 
This directory also exists, even if Clip does not have one. AV stream file is put 
on the bottom of an "M2TS" directory. This directory exists, even if one does 
not have AV stream file. As for the "DATA" directory, the file of data 
broadcasting, such as digital TV broadcast, is stored. 
[0112] A "DVR" directory stores the file shown below. It is made under a 
"info.dvr" file and a DVR directory, and the overall information on an 
application layer is stored. Only one info.dvr must be in the bottom of a DVR 
directory. A file name presupposes that it is fixed to info.dvr. A "menu.thmb" 
file stores the information relevant to a menu thumbnail image. Zero or one 
menu thumbnail must be in the bottom of a DVR directory. A file name 
presupposes that it is fixed to memu.thmb. When one does not have a menu 
thumbnail image, this file does not need to exist. 

[01 13] A "mark.thmb" file stores the information relevant to a mark thumbnail 
image. Zero or one mark thumbnail must be in the bottom of a DVR directory. 
A file name presupposes that it is fixed to mark.thmb. When one does not 



have a menu thumbnail image, this file does not need to exist. 
[01 14] A "PLAYLIST" directory stores two kinds of PlayList files, and they are 
Real PlayList and Virtual PlayList. "xxxxx.rpls" A file stores the information 
relevant to one Real PlayList. One file is made for every Real PlayList. A file 
name is "xxxxx.rpls." Here, "xxxxx" is a figure to five 0 thru/or 9. A file 
extension child presupposes that it must be "rpls". 

[01 15] A "yyyyy.vpls" file stores the information relevant to one Virtual PlayList. 
One file is made for every Virtual PlayList. A file name is "yyyyy.vpls." Here, 
"yyyyy" is a figure to five 0 thru/or 9. A file extension child presupposes that it 
must be "vpls". 

[01 16] A "CLIPINF" directory stores one file corresponding to each AV stream 
file, "zzzzz.clpi" A file is Clip Information file corresponding to one AV stream 
file (Clip AV stream file or Bridge-Clip AV stream file). A file name is 
"zzzzz.clpi" and "zzzzz" is a figure to five 0 thru/or 9. A file extension child 
presupposes that it must be "dpi". 

[0117] An "M2TS" directory stores the file of AV stream. A "zzzzz.m2ts" file is 
an AV stream file treated by the DVR system. This is Clip AV stream file or 
Bridge-Clip AV stream. A file name is "zzzzz.m2ts" and "zzzzz" is a figure to 
five 0 thru/or 9. A file extension child presupposes that it must be "m2ts." 
[01 18] The "DATA" directory stores the data transmitted from data 
broadcasting, and data are for example, XML file, an MHEG file, etc. 
[0119] Next, the syntax and semantics of each directory (file) are explained. 
First, a "info.dvr" file is explained. Drawing 15 is drawing showing the syntax 
of a "info.dvr" file. A "info.dvr" file consists of three objects and they are 
DVRVolume(), TableOfPlayLists(), and MakersPrivateDataQ. 
[0120] TableOfPlayLists_Start_address shows the start address of 
TableOfPlayList() for explaining the syntax of info.dvr shown in drawing 15 by 
making the relative byte count from the cutting tool of the head of an info.dvr 
file into a unit. A relative byte count is counted from zero. 
[0121] MakersPrivateData_Start_address shows the start address of 
MakersPrivateData() by making the relative byte count from the cutting tool of 
the head of an info.dvr file into a unit. A relative byte count is counted from 
zero. padding_word (padding WORD) is inserted according to the syntax of 



info.dvr. N1 and N2 are the positive integers of zero or arbitration. You may 
make it each padding WORD take any value. 

[0122] DVRVolume() stores the information which describes the content of 
volume (disk). Drawing 16 is drawing showing the syntax of DVRVolume(). 
version_number shows four character alphabetic characters which show the 
version number of this DVRVolume() for explaining the syntax of DVR 
Volume() shown in drawing 16 . version_number is encoded with "0045" 
according to ISO 646. 

[0123] length is expressed with the 32-bit unsigned integer which shows the 
byte count of DVRVolume() from immediately after this length field to the last 
of DVRVolume(). 

[0124] ResumeVolumeO has memorized the file name of Real PlayList 
reproduced at the end in volume, or Virtual PlayList. However, a playback 
location when a user interrupts playback of Real PlayList or Virtual PlayList is 
stored in resume-mark defined in PlayListMark() ( drawing 42 , drawing 43 ). 
[0125] Drawing 17 is drawing showing the syntax of ResumeVolume(). For 
explaining the syntax of ResumeVolumeO shown in drawing 17 , valid_flag 
shows that the resume_PlayList_name field is invalid, when it is shown that 
the resume_PlayList_name field is effective when this 1-bit flag is set to 1 and 
this flag is set to 0. 

[0126] 10 bytes of field of resume_PlayList_name shows the file name of Real 
PlayList by which resume should be carried out, or Virtual PlayList. 
[0127] UlApplnfoVolume in the syntax of DVRVolume() shown in drawing 16 
The parameter of the user interface application about volume is stored. The 8- 
bit field of character_set shows the coding approach of the character 
alphabetic character encoded in the Volume_name field for drawing 18 to be 
drawing showing the syntax of UlApplnfoVolume, and explain the semantics. 
The coding approach corresponds to the value shown in drawing 19 . 
[0128] Eight bit fields of namejength show the cutting tool length of a volume 
name shown in the Volume_name field. The field of Volume_name shows the 
name of volume. The byte count of the left in this field to a namejength 
number is an effective character alphabetic character, and it shows the name 
of volume. In the Volume_name field, as for the value after these effective 



characters alphabetic character, what kind of value may be in close. 
[0129] Volume_protect_flag is a flag which shows whether the contents in 
volume may be shown without restricting to a user. Only when this flag is set 
to 1 and a user is able to input an PIN number (password) correctly, showing 
a user the contents of that volume (reproduced) is permitted. When this flag is 
set to 0, even if a user does not input an PIN number, showing a user the 
contents of that volume is permitted. 

[0130] If a user is able to input an PIN number correctly even if first this flag is 
set to 0 or this flag is set to 1 , when a user inserts a disk in a player, as for the 
record regenerative apparatus 1 , the list of PlayList in that disk will be 
displayed. The playback limit of each PlayList is unrelated to 
volume_protect_flag, and it is shown by playback_control_flag defined in 
UIApplnfoPlayList(). 

[0131] PIN consists of figures to four 0 thru/or 9, and each figure is encoded 
according to ISO/I EC 646. The field of reMhumbnailJndex shows the 
information on the thumbnail image added to volume. In the case of the value 
whose reMhumbnail_index field is not OxFFFF, the thumbnail image is added 
to the volume and the thumbnail image is stored in the menu.thum file. The 
image is referred to using the value of ref_thumbnail_index in a menu.thum 
file, the ref_thumbnail_index field -- OxFFFF it is - a case — the volume - a 
thumbnail image adding -- having - **** - things - being shown . 
[0132] Next, TableOfPlayLists() in the syntax of info.dvr shown in drawing 15 
is explained. TableOfPlayLists() stores the file name of PlayList (Real PlayList 
and Virtual PlayList). All the PlayList files currently recorded on volume are 
included in TableOfPlayList(). TableOfPlayListsQ shows the default playback 
sequence of PlayList in volume. 

[0133] version_number of TableOfPlayLists shows four character alphabetic 
characters which show the version number of this TableOfPlayLists for 
drawing 20 to be drawing showing the syntax of TableOfPlayLists(), and 
explain that syntax. version_number must be encoded with "0045" according 
to ISO 646. 

[0134] length is an integer without a 32-bit sign which shows the byte count of 
TableOfPlayListsQ from immediately after this length field to the last of 



TableOfPlayLists(). The 16-bit field of number_of_Play Lists shows the loop 
count of for-loop containing PlayList_file_name. This figure must be equal to 
the number of PlayList(s) currently recorded on volume. 10 bytes of figure of 
PlayList_file_name shows the file name of PlayList. 

[0135] Drawing 21 is drawing showing another configuration of the syntax of 
TableOfPlayLists(). The syntax shown in drawing 21 is considered as the 
configuration in which UlAppinfoPlayList (after-mentioned) was included in the 
syntax shown in drawing 20 . Thus, it becomes possible only by reading 
TableOfPlayLists to create a menu screen by considering as the configuration 
in which UlAppinfoPlayList was included. Here, the following explanation is 
given noting that the syntax shown in drawing 20 is used. 
[0136] MakersPrivateData in the syntax of info.dvr shown in drawing 15 is 
explained. MakersPrivateData is prepared so that the manufacturer of the 
record regenerative apparatus 1 can insert a manufacturer's private data into 
MakersPrivateDataQ for the special application of each company. Each 
manufacturer's private data has makerJD standardized in order to identify the 
manufacturer who defined it. MakersPrivateData() may also contain one or 
more makerJD. 

[0137] When a predetermined manufacturer wants to insert private data and 
other manufacturers' private data is already contained in MakersPrivateData(), 
other manufacturers add new private data into MakersPrivateDataQ rather 
than eliminate the old private data which already exists. Thus, in the gestalt of 
this operation, two or more manufacturers' private data carries out as [ be / 
being contained in one MakersPrivateData() / possible ]. 
[0138] Drawing 22 is drawing showing the syntax of MakersPrivateData. 
version_number shows four character alphabetic characters which show the 
version number of this MakersPrivateData() for explaining the syntax of 
MakersPrivateData shown in drawing 22 . version_number must be encoded 
with "0045" according to ISO 646. length shows the 32-bit unsigned integer 
which shows the byte count of MakersPrivateDataQ from immediately after 
this length field to the last of MakersPrivateData(). 

[0139] mpd_blocks_start_address shows the head byte address of the first 
mpd_block() by making the relative byte count from the cutting tool of the 



head of MakersPrivateDataQ into a unit. A relative byte count is counted from 
zero. number_of_maker_entries is a 16-bit unsigned integer which gives the 
number of entries of the manufacturer private data contained in 
MakersPrivateData(). Two or more manufacturer private data which have the 
value of the same makerJD in MakersPrivateDataQ must not exist. 
[0140] mpd_block_size is a 16-bit unsigned integer which gives the magnitude 
of one mpd__block by making 1024 bytes into a unit. For example, if it 
becomes mpd_block_size=1 , it shows that the magnitude of one mpd_block is 
1024 bytes. number_of_j7ipd_blocks is a 16-bit unsigned integer which gives 
the number of mpd_block contained in MakersPrivateData(). makerJD is a 
16-bit unsigned integer which shows the manufacture manufacturer of the 
DVR system which created the manufacturer private data. The value encoded 
by makerJD is specified by the licenser of this DVR format. 
[0141] makerjriodeLcode is a 16-bit unsigned integer which shows the 
model number code of the DVR system which created the manufacturer 
private data. The value encoded by maker_model„code is set up by the 
carrier beam manufacture manufacturer in the license of this format. 
start_mpd_block_number is a 16-bit unsigned integer which shows the 
number of mpd_b!ock by which the manufacturer private data is started. The 
aryne of the initial data of manufacturer private data must be carried out to the 
head of mpd_block. start_mpd_block_number corresponds to the variable j in 
for-loop of mpd_block. 

[0142] mpdjength is a 32-bit unsigned integer which shows the magnitude of 
manufacturer private data per cutting tool. mpd_block is a field in which 
manufacturer private data is stored. All mpd_block in MakersPrivateDataQ 
must be the same sizes. 

[0143] Next, xxxxx.rpls and yyyyy.vpls will be explained if it puts in another 
way about Real PlayList file and Virtual PlayList file. Drawing 23 is drawing 
showing the syntax of xxxxx.rpls (Real PlayList) or yyyyy.vpls (Virtual 
PlayList). xxxxx.rpls and yyyyy.vpls have the same syntax configuration, 
xxxxx.rpls and yyyyy.vpls consist of three objects, respectively, and they are 
PlayList(), PlayListMark(), and MakersPrivateDataQ. 

[0144] PlayListMark_Start_address shows the start address of PlayListMarkQ 



by making the relative byte count from the cutting tool of the head of a 
PlayList file into a unit. A relative byte count is counted from zero. 
[0145] MakersPrivateData_Start_address shows the start address of 
MakersPrivateData() by making the relative byte count from the cutting tool of 
the head of a PlayList file into a unit. A relative byte count is counted from 
zero. 

[0146] padding_word (padding WORD) is inserted according to the syntax of a 
PlayList file, and N1 and N2 are the positive integers of zero or arbitration. 
You may make it each padding WORD take any value. 
[0147] Here, although already explained simple, PlayList is explained further. 
Refer to the playback section in all Clip(s) except Bridge-Clip (after- 
mentioned) for all Real PlayList in a disk. And two or more RealPlayList(s) 
must not make the playback section shown by those Playltem(s) overlap in 
the same Clip. 

[0148] As shown, Real PlayList to which all Clip(s) correspond exists in 
explaining further with reference to drawing 24 at drawing 24 (A). This 
regulation is followed after an editing task is performed, as shown in drawing 
24 (B). therefore, all Clip(s) - which — it is - surely viewing and listening is 
possible by referring to Real PlayList. 

[0149] As shown in drawing 24 (C), the playback section of Virtual PlayList 
must be included in the playback section of Real PlayList, or the playback 
section of Bridge-Clip. Bridge-Clip referred to at no Virtual PlayList must not 
exist in a disk. 

[0150] Although Real PlayList includes the list of Playltem, it must not contain 
SubPlayltem. When CPLtype Virtual PlayList is indicated to be in PlayListQ 
including the list of Playltem is EP_map type and PlayLisMype is 0 (PlayList 
containing video and an audio), Virtual PlayList can contain one SubPlayltem. 
In PlayListQ in the gestalt of this operation, SubPlaylte must be used only for 
the object of postrecording of an audio and the number of SubPlayltem(s) 
which one Virtual PlayList has must be 0 or 1. 

[0151] Next, PlayList is explained. Drawing 25 is drawing showing the syntax 
of PlayList. They are four character alphabetic characters in which 
version_number shows the version number of this PlayListQ for explaining the 



syntax of PlayList shown in drawing 25 . version_number must be encoded 
with "0045" according to ISO 646. length is a 32-bit unsigned integer which 
shows the byte count of PlayList() from immediately after this length field to 
the last of PlayList(). PlayList_type is the 8-bit field which shows the type of 
this PlayList, and shows that example to drawing 26 . [0152] CPLtype is a 1- 
bit flag and shows the value of CPLtype of Clip referred to by Playltem() and 
SubPlayltem(). All Clip(s) referred to by one PlayList must have the the same 
value of CPLtype defined in those CPIQ. number_oLPIayltems is the 16-bit 
field which shows the number of Playltem(s) in PlayList. 
[0153] Playltemjd corresponding to predetermined Playltem() is defined in 
for-loop containing PlayltemQ by the sequence that the Playltem() appears. 
Playltemjd is started from 0. number_of_SubPlayltems is the 16-bit field 
which shows the number of SubPlayltem(s) in PlayList. This value is 0 or 1 . 
The pass (audio stream pass) of an additional audio stream is a kind of 
subpass. 

[0154] Next, UlApplnfoPlayList of the syntax of PlayList shown in drawing 25 
is explained. UlApplnfoPlayList stores the parameter of the user interface 
application about PlayList. Drawing 27 is drawing showing the syntax of 
UlApplnfoPlayList. For explaining the syntax of UlApplnfoPlayList shown in 
drawing 27 , character_set is the 8-bit field and shows the coding approach of 
the character alphabetic character encoded in the PlayList_name field. The 
coding approach corresponds to the value based on the table shown in 
drawing 19 . 

[0155] namejength is eight bit fields and shows the cutting tool length of the 
PlayList name shown in the PlayLisLname field. The field of PlayLisLname 
shows the name of PlayList. The byte count of the left in this field to a 
namejength number is an effective character alphabetic character, and it 
shows the name of PlayList. In the PlayLisLname field, as for the value after 
these effective characters alphabetic character, what kind of value may be in 
close. 

[0156] record Jime_and_date is the 56-bit field in which time when PlayList is 
recorded is stored. This field encodes 14 figures by 4-bit Binary Coded 
Decimal (BCD) about a /part / second at the time of year / moon / day/. For 



example, 2001/12/23:01:02:03 It encodes with "0x20011223010203." 
[0157] duration is the 24-bit field which showed the total playback time 
amount of PlayList in the unit of time amount / part / second. This field 
encodes six figures by 4-bit Binary CodedDecimal (BCD). For example, 
01:45:30 is encoded with "0x014530." 

[0158] valid_period is the 32-bit field which shows the period when PlayList is 
effective. This field encodes eight figures by 4-bit Binary Coded Decimal 
(BCD). For example, the record regenerative apparatus 1 is used as it said 
that automatic elimination of the PlayList over which this shelf-life passed was 
carried out. For example, 2001/05/07 It encodes with "0x20010507." 
[0159] makeMd is a 16-bit unsigned integer which shows the manufacturer of 
the DVR player (record regenerative apparatus 1) which updated the PlayList 
at the end. The value encoded by makeMd is assigned by the licenser of a 
DVR format. maker_code is a 16-bit unsigned integer which shows the model 
number of the DVR player which updated the PlayList at the end. The value 
encoded by maker_code is decided by the carrier beam manufacturer in the 
license of a DVR format. 

[0160] The PlayList is reproduced, only when the flag of playback_controLflag 
is set to 1 and a user is able to input an PIN number correctly. When this flag 
is set to 0, even if a user does not input an PIN number, a user can view and 
listen to that PlayList. 

[0161] As a table is shown in drawing 28 (A), when write_protect_flag is set to 
1, write_protect_flag is removed, and the content of the PlayList is not 
eliminated and changed. When this flag is set to 0, a user can eliminate and 
change that PlayList freely. When this flag is set to 1 , before a user eliminates, 
edits or overwrites that PlayList, the record regenerative apparatus 1 displays 
a message which is reconfirmed to a user. 

[0162] Virtual PlayList which Real PlayList by which write_protect_flag is set to 
0 exists, and refers to Clip of the Real PlayList exists, and write_protect_flag 
of the Virtual PlayList may be set to 1. "Minimize" [ regenerative apparatus / it 
warns a user of existence of Above Virtual PlayList, or / the Real PlayList ] 
before the record regenerative apparatus 1 eliminates the Real PlayList when 
a user is going to eliminate RealPlayList. 



[0163] As is_played_flag is shown in drawing 28 (B), when it is shown that it 
was reproduced at once after the PlayList was recorded when the flag was set 
to 1 and it is set to 0, the PlayList shows not being reproduced once, after 
being recorded. 

[0164] archive is the 2-bit field which shows whether the PlayList is original or 
it is copied, as shown in drawing 28 (C). refJhumbnaiUndex The field shows 
the information on a thumbnail image that PlayList is represented. In the case 
of the value whose ref_thumbnaiLindex field is not OxFFFF, the thumbnail 
image representing PlayList is added to the PlayList, and the thumbnail image 
is menu.thum. It is stored in the file. The image is referred to using the value 
of ref_thumbnail_index in a menu.thum file, the reMhumbnailJndex field - 
OxFFFF it is - a case - the PlayList » PlayList -- representing - a thumbnail - 
- an image — adding - having -- **** . 

[0165] Next, Playltem is explained. One Playltem() contains the following data 
fundamentally. When CPUype defined in the pair of INLtime for specifying 
Clip_information_file_name for specifying the file name of Clip and the 
playback section of Clip and OUT_time and PlayList() is EP_map type, they 
are STC_sequenceJd which IN_time and OUT__time refer to, and 
connection_condition which shows the condition of connection between 
Playltem to precede and current Playltem. 

[0166] Those Playltem(s) are arranged in on the global time-axis of PlayList 
without the gap of time amount, or overlap by the single tier when PlayList 
consists of two or more Playltem(s). CPUype defined in PlayList() is EP_map 
type, and the pair of IN_time defined in the Playltem when the present 
Playltem does not have BridgeSequence(), and OUTJime must point out the 
time amount on the same STC continuation section specified by 
STC_sequence_id. Such an example is shown in drawing 29 . 
[0167] CPUype defined in PlayListQ is EP_map type, and drawing 30 shows 
the case where the regulation explained below is applied, when the present 
Playltem has BridgeSequence(). IN_time (what is indicated to be IN_time1 in 
drawing) of Playltem preceded with current Playltem has pointed out the time 
amount on the STC continuation section specified by STC_sequenceJd of 
Playltem to precede. OUTJime (what is indicated to be OUTJime 1 in 



drawing) of Playltem to precede has pointed out the time amount in Bridge- 
Clip specified in BridgeSequencelnfo() of current Playltem. This OUTJime 
must follow the coding limit mentioned later. 

[0168] INJime (what is indicated to be INJime2 in drawing) of current 
Playltem has pointed out the time amount in Bridge-Clip specified in 
BridgeSequencelnfo() of current Playltem. This INJime must also follow the 
coding limit mentioned later. OUT_time (what is indicated to be OUT_time2 in 
drawing) of Playltem of current Playltem has pointed out the time amount on 
the STC continuation section specified by STC_sequencejd of current 
Playltem. 

[0169] As shown in drawing 31 , when CPLtype of PlayList() is TU_map type, 
the pair of IN_time of Playltem and OUTJime has pointed out the time 
amount on the same Clip AV stream. 

[0170] The syntax of Playltem comes to be shown in drawing 32 . The field of 
Clip_lnformation_file_name shows the file name of Cliplnformation file for 
explaining the syntax of Playltem shown in drawing 32 . Clip_stream_type 
defined in Cliplnfo() of this Clip Information file must show Clip AV stream. 
[0171] STC_sequence_id is the 8-bit field and shows STC_sequence_id of the 
STC continuation section which Playltem refers to. When CPLtype specified 
in PlayList() is TU_map type, these eight bit fields have no semantics, but are 
set to 0. IN_time is 32 bit fields and stores the playback start time of Playltem. 
The semantics of INJime changes with CPLtype defined in PlayListQ, as 
shown in drawing 33 . 

[0172] OUTJime is 32 bit fields and stores the playback end time of Playltem. 
The semantics of OUTJime changes with CPLtype defined in PlayList(), as 
shown in drawing 34 . 

[0173] Connection_Condition is the 2-bit field which shows the connection 
condition between Playltem to precede as shown in drawing 35 , and the 
present Playltem. Drawing 36 is drawing explaining each condition of 
Connection_Condition shown in drawing 35 . 

[0174] Next, BridgeSequencelnfo is explained with reference to drawing 37 . 
BridgeSequencelnfoQ is the attached information on current Playltem, and 
has the information shown below. Bridge_ClipJnformation_file_name which 



specifies Clip Information file ( drawing 45 ) corresponding to a Bridge-Clip AV 
stream file and it is included. 

[0175] Moreover, it is the address of the source packet on Clip AV stream 
which Playltem to precede refers to, and the source packet of the beginning of 
a Bridge-Clip AV stream file is connected following this source packet. This 
address is called RSPN_exit_from_previous_Clip. It is the address of the 
source packet on Clip AV stream which further current Playltem refers to, and 
the source packet of the last of a Bridge-Clip AV stream file is connected 
before this source packet. This address is called RSPN_enter_to_current_Clip. 
[0176] In drawing 37 , RSPN_arrival_time_discontinuity shows the address of 
the source packet which has the break point of arrival time base in a the 
Bridge-Clip AVstream file. This address is defined in Cliplnfo() ( drawing 46 ). 
[0177] Drawing 38 is drawing showing the syntax of BridgeSequenceinfo. The 
field of Bridge_ClipJnformation_file_name shows the file name of Clip 
Information file corresponding to a Bridge-Clip AV stream file for explaining 
the syntax of BridgeSequenceinfo shown in drawing 38 . Clip_stream_type 
defined in Cliplnfo() of this Clip Information file must show 'Bridge-Clip AV 
stream 1 . 

[0178] 32 bit fields of RSPN_exit_from_previous_Clip are the relative 
addresses of the source packet on Clip AV stream which Playltem to precede 
refers to, and the source packet of the beginning of a Bridge-Clip AV stream 
file is connected following this source packet. RSPN_exit_from_previous_Clip 
is magnitude which makes a source packet number a unit, and counts the 
value of offset_SPN defined in Cliplnfo() from the source packet of the 
beginning of the Clip AV stream file which Playltem to precede refers to as 
initial value. 

[0179] 32 bit fields of RSPN_enter_to_current_Clip are the relative addresses 
of the source packet on Clip AV stream which current Playltem refers to, and 
the source packet of the last of a Bridge-Clip AV stream file is connected 
before this source packet. RSPN_exit_from_previous_Clip is magnitude which 
makes a source packet number a unit, and counts the value of offset_SPN 
defined in Cliplnfo() from the source packet of the beginning of the Clip AV 
stream file which current Playltem refers to as initial value. 



[0180] Next, SubPlayltem is explained with reference to drawing 39 . The 
activity of SubPlayltem() is allowed only when CPLtype of PlayList() is 
EP_map type. In the gestalt of this operation, SubPlayltem presupposes that it 
is used only for the object of postrecording of an audio. SubPlayltem() 
contains the data shown below. First, Clip_information_file_name for 
specifying Clip which sub path in PlayList refers to is included. 
[0181] Moreover, SubPathJNJime for specifying the playback section of sub 
path in Clip SubPath_OUT_time is included. Furthermore, sync_Playltem_id 
for specifying the time of day in which sub path carries out playback initiation 
on the time-axis of main path sync_start_PTS_of_PIayltem is included. Clip 
AV stream of the audio referred to at sub path must not contain an STC break 
point (break point of system time base). The clock of the audio sample of Clip 
used for sub path is locked by the clock of the audio sample of main path. 
[0182] Drawing 40 is drawing showing the syntax of SubPlayltem. The field of 
ClipJnformation_file_name shows the file name of Clip Information file for 
explaining the syntax of SubPlayltem shown in drawing 40 , and it is used by 
sub path in PlayList. Clip_stream_type defined in CliplnfoQ of this Clip 
Information file must show Clip AV stream. 

[0183] The 8-bit field of SubPath_type shows the type of sub path. Here, as 
shown in drawing 41 , only '0x00' is set up but other values are secured for 
the future. 

[0184] The 8-bit field of sync_Playltem_id shows Playltemjd of Playltem in 
which the time of day sub path carries out [ time of day ] playback initiation on 
the time-axis of main path is contained. The value of Playltemjd 
corresponding to predetermined Playltem is defined in PlayList() (refer to 
drawing 25 ). 

[0185] The 32-bit field of sync_start_PTS_oLPIayltem shows the time of day 
in which sub path carries out playback initiation on the time-axis of main path, 
and shows 32 bits of high orders of PTS on Playltem referred to by 
sync_Playltem_id (Presentaiotn Time Stamp). 32 bit fields of 
SubPathJNLtime store the playback start time of Sub path. SubPathJN_time 
shows 32 bits of high orders of PTS of 33 bit length corresponding to the first 
presentation unit in Sub Path. 



[0186] 32 bit fields of SubPathjDUTJime store the playback end time of Sub 
path. SubPath_OUT_time shows 32 bits of high orders of the value of 
Presenation_end_TS computed by the degree type. Presentation_end_TS = 
PTS_out+AU_duration - here, PTS_out is PTS of 33 bit length corresponding 
to the presentation unit of the last of SubPath. AU_duration is the display 
period of the 90kHz unit of the presentation unit of the last of SubPath. 
[0187] Next, PlayListMark() in the syntax of xxxxx.rpls shown in drawing 23 
and yyyyy.vpls is explained. The mark information about PlayList is stored in 
this PlayListMark. Drawing 42 is drawing showing the syntax of PlayListMark. 
They are four character alphabetic characters in which version_number shows 
the version number of this PlayListMark() for explaining the syntax of 
PlayListMark shown in drawing 42 . version_number must be encoded with 
"0045" according to ISO 646. 

[0188] length is a 32-bit unsigned integer which shows the byte count of 
PlayListMark() from immediately after this length field to the last of 
PlayListMark(). number_of_PlayList_marks is a 16-bit unsigned integer which 
shows the number of the mark currently stored in PlayListMark. 
number_of_PlayList_marks You may be 0. mark_type is the 8-bit field which 
shows the type of a mark, and is encoded according to the table shown in 
drawing 43 . 

[0189] 32 bit fields of mark_time_stamp store the time stump in which the 
point with which the mark was specified is shown. The semantics of 
mark_time_stamp changes with CPLtype defined in PlayList(), as shown in 
drawing 44 . Playltemjd is the 8-bit field which specifies Playltem on which 
the mark is put. The value of Playltemjd corresponding to predetermined 
Playltem is defined in PlayList() (refer to drawing 25 ). 
[0190] The 8-bit field of character_set shows the coding approach of the 
character alphabetic character encoded by the mark_name field. The coding 
approach corresponds to the value shown in drawing 19 . Eight bit fields of 
namejength show the cutting tool length of the mark name shown in the 
Mark_name field. The field of mark_name shows the name of a mark. The 
byte count of the left in this field to a namejength number is an effective 
character alphabetic character, and it shows the name of a mark. As for the 



value after these effective characters alphabetic character, what kind of value 
may be set up in the Mark_name field. 

[0191] The field of ref_thumbnail_index shows the information on the 
thumbnail image added to a mark. In the case of the value whose 
reMhumbnaiLindex field is not OxFFFF, the thumbnail image is added to the 
mark and the thumbnail image is stored in the mark.thmb file. The image is 
referred to using the value of reMhumbnaiLindex in a mark.thmb file (after- 
mentioned), the reMhumbnaiLindex field - OxFFFF it is - a case - the mark 
- a thumbnail image - adding - having -- **** - things - being shown . 
[0192] Next, Clip information file is explained, zzzzz.clpi (Clip information file 
file) consists of six objects, as shown in drawing 45 . They are Cliplnfo(), 
STCJnfo(), Programlnfo(), CPI(), ClipMark(), and MakersPrivateData(). 
"zzzzz" of the digit string with the same Clip Information file corresponding to 
AV stream (a Clip AV stream or Bridge-Clip AV stream) and it is used. 
[0193] Cliplnfo_Start_address shows the start address of Cliplnfo() for 
explaining the syntax of zzzzz.clpi (Clip information file file) shown in drawing 
45 by making the relative byte count from the cutting tool of the head of a 
zzzzz.clpi file into a unit. A relative byte count is counted from zero. 
[0194] STCJnfo__Start_address shows the start address of STC_lnfo() by 
making the relative byte count from the cutting tool of the head of a zzzzz.clpi 
file into a unit. A relative byte count is counted from zero. 
Programlnfo_Start_address shows the start address of Programlnfo() by 
making the relative byte count from the cutting tool of the head of a zzzzz.clpi 
file into a unit. A relative byte count is counted from zero. CPI_Start_address 
shows the start address of CPI() by making the relative byte count from the 
cutting tool of the head of a zzzzz.clpi file into a unit. A relative byte count is 
counted from zero. 

[0195] ClipMark_Start_address shows the start address of ClipMark() by 
making the relative byte count from the cutting tool of the head of a zzzzz.clpi 
file into a unit. A relative byte count is counted from zero. 
MakersPrivateData_Start_address shows the start address of 
MakersPrivateData () by making the relative byte count from the cutting tool of 
the head of a zzzzz.clpi file into a unit. A relative byte count is counted from 



zero. padding_word (padding WORD) is inserted according to the syntax of a 
zzzzz.clpi file. N1, N2, N3, N4, and N5 must be the positive integers of zero or 
arbitration. As for each padding WORD, any value may be made to be taken. 
[0196] Next, Cliplnfo is explained. Drawing 46 is drawing showing the syntax 
of Cliplnfo. Cliplnfo() stores the attribute information on AV stream file (a Clip 
AV stream or Bridge-Clip AV stream file) corresponding to it. 
[0197] They are four character alphabetic characters in which version_number 
shows the version number of this Cliplnfo() for explaining the syntax of 
Cliplnfo shown in drawing 46 . version_number must be encoded with "0045" 
according to ISO 646. length is a 32-bit unsigned integer which shows the 
byte count of Cliplnfo() from immediately after this length field to the last of 
CliplnfoQ. The 8-bit field of Clip_stream_type shows the type of AV stream 
corresponding to a Clip Information file, as shown in drawing 47 . About the 
stream type of each type of AV stream, it mentions later. 
[0198] The 32-bit field of offset_SPN gives the offset value of the source 
packet number about the source packet of the beginning of AV stream (Clip 
AV stream or Bridge-Clip AV stream) file. This offset_SPN must be 0 when AV 
stream file is first recorded on a disk. 

[0199] As shown in drawing 48 , when the first part of AV stream file is 
eliminated by edit, offset_SPN is very good in values other than zero. The 
relative source packet number (relative address) which refers to offset_SPN 
with the gestalt of this operation is often RSPN_xxx (xxx deforms.). It is 
described by in the form of example .RSPN_EP_start in syntax. A relative 
source packet number is magnitude which makes a source packet number a 
unit, and counts the value of offset_SPN as initial value from the source 
packet of the beginning of AV stream file. 

[0200] The number (SPN_xxx) of the source packets to the source packet 
referred to by the relative source packet number from the source packet of the 
beginning of AV stream file is computed by the degree type. 
An example in case offset_SPN is 4 is shown in SPN_xxx = RSPN_xxx- 
offset_SPN drawing 48 . 

[0201] TS_recording_rate — a 24-bit unsigned integer - it is — this value — a 
DVR drive (write-in section 22) - or the bit rate of required I/O of AV stream 



from a DVR drive (read-out section 28) is given. record_time_and_date is the 
56-bit field in which time when AV stream corresponding to Clip is recorded is 
stored, and encodes 14 figures by 4-bit Binary Coded Decimal (BCD) about a 
/part / second at the time of year / moon / day/. For example, 
2001/12/23:01:02:03 are encoded with "0x20011223010203." 
[0202] duration is the 24-bit field which showed the total playback time 
amount of Clip in the unit of time amount / part / second based on an arrival 
timer clock. This field encodes six figures by 4-bit Binary Coded Decimal 
(BCD). For example, 01:45:30 is encoded with "0x014530." 
[0203] The flag of time_controlled_flag shows the recording mode of AV 
stream file. When this time_controlled_flag is 1, a recording mode must fulfill 
the conditions which show that it is the mode in which it is recorded to the 
time amount progress after recording as a file size is proportional, and are 
shown in a degree type. 

TS__average_rate*192/188*(t-start_time)-alpha <= size_clip (t) - 
<=TS_average_rate*192/188*(t-startJime) +alpha -- here - TS_average_rate 
— the average bit rate of the transport stream of AV stream file — 
bytes/second a unit - a table - it is a thing the bottom. 
[0204] Moreover, in a top type, t shows the time amount expressed per 
second, and start_time is time of day when the source packet of the beginning 
of AV stream file is recorded, and is expressed per second. size_clip (t), 
When the size of AV stream file in time of day t is expressed per cutting tool, 
for example, ten source packets are recorded by time of day t from start_time, 
size_clip (t) is 10*192 bytes, alpha is a constant depending on 
TS_average_rate. 

[0205] When time_controlled_flag is set to 0, not controlling the recording 
mode so that the file size of AV stream is proportional to time amount 
progress of record is shown. For example, this is the case where transparent 
record of the input transport stream is carried out. 

[0206] When, as for TS_average_rate, time_controlled_flag is set to 1, this 24- 
bit field shows the value of TS_average_rate used by the top formula. When 
time_controlled_flag is set to 0, this field has no semantics but must be set to 
0. For example, the transport stream of a Variable Bit Rate is encoded by the 



procedure shown below. A transformer portrait is first set to the value of 
TS_recording_rate. Next, a video stream is encoded with a Variable Bit Rate. 
And a transport packet is intermittently encoded by not using Nur Paquette. 
[0207] 32 bit fields of RSPN_arrivalJime_discontinuity are the relative 
addresses of the location which the discontinuity of arrival time base 
generates on a Bridge-Clip AV stream file. RSPN„arrival_time_discontinuity is 
magnitude which makes a source packet number a unit, and is Cliplnfo() from 
the source packet of the beginning of a Bridge-Clip AV stream file. The value 
of offset_SPN set and defined is counted as initial value. The absolute 
address in the inside of the Bridge-Clip AV stream file is computed based on 
SPN_xxx = RSPN„xxx-offset_SPN mentioned above. 

[0208] The 144-bit field of reserved Jor_system_use is reserved for systems. 
When the flag of is_formaUdentifier_valid is 1, it is shown that the field of 
format_identifier is effective. When the flag of is_original_networkJD_valid is 1, 
it is shown that the field of original_network_ID is effective. When the flag of 
isJransport_streamJD_valid is 1, it is shown that the field of 
transport_streamJD is effective. When the flag of is_serveceJD_valid is 1, it 
is shown that the field of serveceJD is effective. 

[0209] When the flag of is_country_code_valid is 1, it is shown that the field of 
country_code is effective. 32 bit fields of format_identifier show the value of 
format_identifier which registration deascriotor (it defines as ISO/IEC 13818-1) 
has in a transport stream. 16 bit fields of originaLnetworkJD show the value 
of originaLnetworkJD defined in the transport stream. 16 bit fields of 
transport_streamJD show the value of transport_streamJD defined in the 
transport stream. 

[0210] 16 bit fields of serveceJD show the value of serveceJD defined in the 
transport stream. The 24-bit field of country_code shows the country code 
defined by IS03166. Each character alphabetic character is encoded by ISO 
8859-1. For example, Japan is expressed as "JPN" and encoded with "0x4A 
0x500x4E." stream Jormat_name is 16 character codes of ISO-646 which 
show the name of the format engine which is doing the stream definition of a 
transport stream. As for the invalid cutting tool in this field, value'OxFF* is set. 
[0211] formatjdentifier, originaLnetworkJD, transport_streamJD, serveceJD, 



country_code, and stream Jormat_jiame can show the service provider of a 
transport stream, and, thereby, can recognize a coding limit of an audio or a 
video stream, and the stream definition of the specification of SI (service 
information), or private data streams other than an audio video stream. Such 
information can be used, in order that a decoder may perform initial setting of 
a decoder system before decoding initiation whether the stream can be 
decoded and when it can decode and. 

[0212] Next, STCJnfo is explained. Here, the time amount section which does 
not contain the break point (break point of system time base) of STC in an 
MPEG-2 transport stream is called STC_sequence, and STC_sequence is 
specified with the value of STC_sequence_id in Clip. Drawing 50 is drawing 
explaining the STC section [ **** ]. The value of the STC same in the same 
STC_sequence never appears (however, the maximum time amount length of 
Clip is restricted so that it may mention later). Therefore, the same value of 
PTS also never appears in the same STC_sequence. When AV stream 
contains the STC break point of N (N> 0) individual, the system time base of 
Clip is divided into STC_sequence of an individual (N+1). 
[0213] STCJnfo stores the address of the location which the discontinuity 
(discontinuity of system time base) of STC generates. RSPN_STC_start 
shows the address, and k-th STC_sequence (k>=0) except the last 
STC_sequence begins from the time of day when the source packet referred 
to by k-th RSPN_STC_start arrived, and finishes with the time of day when the 
source packet referred to by RSPN_STC_start of eye watch (k+1) arrived so 
that it may explain with reference to drawing 51 . The last STC_sequence 
begins from the time of day when the source packet referred to by the last 
RSPN_STC_start arrived, and is ended at the time of day when the last 
source packet arrived. 

[0214] Drawing 52 is drawing showing the syntax of STCJnfo. They are four 
character alphabetic characters in which versionjiumber shows the version 
number of this STCJnfo() for explaining the syntax of STCJnfo shown in 
drawing 52 . version_number must be encoded with "0045" according to ISO 
646. 

[0215] length is a 32-bit unsigned integer which shows the byte count of 



STC_lnfo() from immediately after this length field to the last of STCJnfoQ. 
When CPLtype of CPI() shows TU_map type, this length field may set zero. 
When CPLtype of CPI() shows EP_map type, num_of_STC_sequences must 
be one or more values. 

[0216] The 8-bit unsigned integer of num_of_STC_sequences shows the 
number of STC_sequence(s) in the inside of Clip. This value shows the loop 
count of for-loop following this field. STC_sequence_id corresponding to 
predetermined STC_sequence is defined in for-loop containing 
RSPN_STC_start by the sequence that RSPN_STC_start corresponding to 
the STC_sequence appears. STC_sequenceJd is started from 0. 
[0217] 32 bit fields of RSPN_STC_start show the address which 
STC_sequence starts on AV stream file. RSPN_STC_start shows the address 
which the break point of system time base generates in AV stream file. 
RSPN_STC_start is good also as a relative address of a source packet which 
has PCR of the beginning of new system time base in AV stream. 
RSPN_STC_start is magnitude which makes a source packet number a unit, 
and counts the value of offset_SPN defined in Cliplnfo() from the source 
packet of the beginning of AV stream file as initial value. The absolute 
address in the inside of the AV stream file is computed by SPN_xxx = 
RSPN_xxx-offset_SPN already mentioned above. 

[0218] Next, Programlnfo in the syntax of zzzzz.clip shown in drawing 45 is 
explained. The time amount section which has the following description in Clip 
is called program_sequence for explaining here, referring to drawing 53 . First, 
the value of PCR_PID does not change. Next, the number of video 
elementary streams does not change. Moreover, the encoded information 
defined by the value and VideoCodinglnfo of PID about each video stream 
does not change. Furthermore, the number of audio elementary streams does 
not change. Moreover, the encoded information defined by the value and 
AudioCodinglnfo of PID about each audio stream does not change. 
[0219] program_sequence has only one system time base in the same time of 
day. program_sequence has only one PMT in the same time of day. 
Programlnfo() stores the address of the location which program_sequence 
starts. RSPN_program_sequence_start shows the address. 



[0220] Drawing 54 is drawing showing the syntax of Programlnfo. They are 
four character alphabetic characters in which version_number shows the 
version number of this Programlnfo() for explaining SHINTAKU of 
Programlnfo shown in drawing 54 . version_number must be encoded with 
"0045" according to ISO 646. 

[0221] length is a 32-bit unsigned integer which shows the byte count of 
Programlnfo() from immediately after this length field to the last of 
ProgramlnfoQ. When CPUype of CPI() shows TU_map type, this length field 
may be set to zero. When CPI_type of CPI() shows EP_map type, 
number_of_programs must be one or more values. 

[0222] The 8-bit unsigned integer of number_of_program_sequences shows 
the number of program_sequence in the inside of Clip. This value shows the 
loop count of for-loop following this field. When program_sequence does not 
change in Clip, number_of_program_sequences must have 1 set. 32 bit fields 
of RSPN_program_sequence„start are the relative addresses of the location 
which a program sequence starts on AV stream file. 

[0223] RSPN_prograrrLsequence_start is magnitude which makes a source 
packet number a unit, and counts the value of offset_SPN defined in Cliplnfo() 
from the source packet of the beginning of AV stream file as initial value. The 
absolute address in the inside of the AV stream file is computed by SPN_xxx 
= RSPN_xxx-offset_SPN. A RSPN_program_sequence_start value must 
appear in ascending order in for-loop of syntax. 

[0224] 16 bit fields of PCR_PID show PID of transport Paquette including the 
PCR field effective in the program__sequence. Eight bit fields of 
number_of_videos show the loop count of video_stream_PID and for-loop 
containing VideoCodinglnfo(). Eight bit fields of number_of_audios show the 
loop count of audio_stream_PID and for-loop containing AudioCodinglnfo(). 
16 bit fields of video_stream_PID show PID of transport Paquette containing a 
video stream effective in the program_sequence. VideoCodinglnfo() following 
this field must explain the content of the video stream referred to by that 
video_stream_PID. 

[0225] 16 bit fields of audio_stream_PID show PID of transport Paquette 
containing an audio stream effective in the program_sequence. 



AudioCodinglnfoQ following this field must explain the content of the video 
stream referred to by that audio_stream_PID. 

[0226] In addition, the sequence that the value of video_stream_PID appears 
in for-loop of syntax must be equal to the sequence that PI D of a video stream 
is encoded in PMT effective in the program_sequence. Moreover, the 
sequence that the value of audio_stream_PID appears in for-loop of syntax 
must be equal to the sequence that PID of an audio stream is encoded in 
PMT effective in the program_sequence. 

[0227] Drawing 55 is drawing showing the syntax of VideoCodinglnfo in the 
syntax of Programinfo shown in drawing 54 . For explaining the syntax of 
VideoCodinglnfo shown in drawing 55 , eight bit fields of video_format show 
the video format corresponding to video_stream_PID in Programlnfo(), as 
shown at drawing 56 . 

[0228] Eight bit fields of frame_rate show the frame rate of the video 
corresponding to video_stream_PID in Programlnfo(), as shown in drawing 
57 . Eight bit fields of display_aspect„ratio show the display aspect ratio of the 
video corresponding to video_stream_PID in Programlnfo(), as shown in 
drawing 58 . 

[0229] Drawing 59 is drawing showing the syntax of AudioCodinglnfo in the 
syntax of Programinfo shown in drawing 54 . For explaining the syntax of 
AudioCodinglnfo shown in drawing 59 , eight bit fields of audio_coding show 
the coding approach of the audio corresponding to audio_stream_PID in 
Programlnfo(), as shown at drawing 60 . 

[0230] Eight bit fields of audio_component_type show the component type of 
the audio corresponding to audio_stream_PID in ProgramlnfoQ, as shown in 
drawing 61 . Eight bit fields of samplingjrequency show the sampling 
frequency of the audio corresponding to audio_stream_PID in Programlnfo(), 
as shown in drawing 62 . 

[0231] Next, CPI in the syntax of zzzzz.clip shown in drawing 45 
(Characteristic Point Information) is explained. Since the hour entry in AV 
stream and the address in the file are associated, there is CPI. There are two 
types of CPI(s) and they are EP_map and TU_map. As shown in drawing 63 , 
when CPLtype in CPIQ is EP_map type, the CPIQ contains EP_map. As 



shown in drawing 64 , when CPIJype in CPI() is TILmap type, the CPI() 
contains TU_map. One AV stream has one EP_map or one TU_map. When 
AV stream is a SESF transport stream, Clip corresponding to it must have 
EP_map. 

[0232] Drawing 65 is drawing showing the syntax of CPI. They are four 
character alphabetic characters in which version_number shows the version 
number of this CPIQ for explaining the syntax of CPI shown in drawing 65 . 
version_number must be encoded with "0045" according to ISO 646. length is 
a 32-bit unsigned integer which shows the byte count of CPI() from 
immediately after this length field to the last of CPI(). As shown in drawing 66 , 
CPLtype is a 1-bit flag and expresses the type of CPI of Clip. 
[0233] Next, EP_map in the syntax of CPI shown in drawing 65 is explained. 
There are two types of EP_map and they are EP_map for video streams, and 
EP_map for audio streams. EP_mapJype in EP_map distinguishes the type 
of EP_map. When Clip contains one or more video streams, EP_map for 
video streams must be used. When Clip contains one or more audio streams 
excluding a video stream, EP_map for audio streams must be used. 
[0234] EP_map for video streams is explained with reference to drawing 67 . 
EP_map for video streams has data called stream_PID, PTS_EP_start, and 
RSPN_EP_start. stream_PID shows PID of transport Paquette who transmits 
a video stream. PTS_EP__start shows PTS of the access unit which begins 
from the sequence header of a video stream. RSPN_EP_start shows the 
address of the source packet containing the 1st byte of the access unit 
referred to by PTS_EP_start in AV stream. 

[0235] The sub table called EP_map_for_one_stream_PID() is made for every 
video stream transmitted by transport Paquette with the same PID. When two 
or more video streams exist in Clip, EP_map may also contain two or more 
E P_map_for_o n e_strea m_P I D () . 

[0236] EP_map for audio streams has data called stream_PID, PTS_EP_start, 
and RSPN_EP_start. stream_PID shows PID of transport Paquette who 
transmits an audio stream. PTS_EP_start shows PTS of the access unit of an 
audio stream. RSPN_EP_start shows the address of the source packet 
containing the 1st byte of the access unit referred to by PTS_EP_start in AV 



stream. 

[0237] The sub table called EP_mapJor_one_stream_PID() is made for every 
audio stream transmitted by transport Paquette with the same PID. When two 
or more audio streams exist in Clip, EP_map may also contain two or more 
EP_map_for_one_stream_PID(). 

[0238] One EP_map_for_one_stream_PID() is made by explaining the relation 
between EP_map and STCJnfo regardless of the break point of STC at one 
table. By comparing the value of RSPN_STC_start defined in the value of 
RSPN_EP_start and STC_lnfo() shows the boundary of the data of EP_map 
belonging to each STC_sequence (see drawing 68 ). - EP_map must have 
one EP_mapJbr_one_stream_PID to the range of the continuous stream 
transmitted by the same PID. When shown in drawing 69 , although 
program#1 and program#3 have the same video PID, since the data range is 
not continuing, they must have EP_map_for_one_stream_PID for every 
program. 

[0239] Drawing 70 is drawing showing the syntax of EP_map. For explaining 
the syntax of EP_jnap shown in drawing 70 , EP_type is the 4-bit field, and as 
shown at drawing 71 , it shows the entry point type of EP_map. EP_type 
shows the semantics of the data field following this field. EP_type must be set 
to 0 (Video') when Clip contains one or more video streams. Or EP_type must 
be set to 1 ('audio 1 ) when Clip contains one or more audio streams excluding 
a video stream. 

[0240] The 16-bit field of number_of_stream_PIDs shows the loop count of for- 
loop which has number_of_stream_PIDs in EP_map() in a variable. The 16-bit 
field of stream_PID (k) shows PID of transport Paquette who transmits the k- 
th elementary stream (video or audio stream) referred to by 
EP_map_for_one_stream_PID (num_EP_entries (k)). case EP_type is equal to 
0 (Video 1 ) — the elementary stream — a video stream - kicking does not 
become impossible Moreover, when EP_type is equal to 1 ('audio 1 ), the 
elementary stream must be an audio stream. 

[0241] The 16-bit field of numJEP_entries (k) shows num_EP_entries (k) 
referred to by EP_map_for_one_stream_PID (num_EP_entries (k)). 
EP_mapJbr_one_stream_PID_Start_address (k): This 32-bit field shows the 



relative byte position from which EP_map_for_one_stream_PID 
(num_EP_entries (k)) begins in EP_map(). This value is shown by the 
magnitude from the 1st byte of EP_map(). 

[0242] padding_word must be inserted according to the syntax of EPjnap(). X 
and Y must be the positive integers of zero or arbitration. Each padding 
WORD may take any value. 

[0243] Drawing 72 is drawing showing the syntax of 
EP_map_for_one_stream_PID. The semantics of the 32-bit field of 
PTS_EP_start changes with EP_type(s) defined in EP_map() to explain the 
syntax of EP_map_for_one_stream_PID shown in drawing 72 . When EP_type 
is equal to 0 (Video 1 ), this field has 32 bits of high orders of PTS of the 33-bit 
precision of the access unit which starts in the sequence header of a video 
stream. When EP_type is equal to 1 ('audio 1 ), this field has 32 bits of high 
orders of PTS of the 33-bit precision of the access unit of an audio stream. 
[0244] The semantics of the 32-bit field of RSPN_EP_start changes with 
EPJype defined in EP_map(). When EPJype is equal to 0 (Video 1 ), this field 
shows the relative address of the source packet containing the 1st byte of the 
sequence header of the access unit referred to by PTS_EP_start in AV stream. 
Or when EP_type is equal to 1 ('audio 1 ), this field shows the relative address 
of the source packet containing the first byte of the audio frame of the access 
unit referred to by PTS_EP_start in AV stream. 

[0245] RSPN_EP_start is magnitude which makes a source packet number a 
unit, and counts the value of offset_SPN defined in Cliplnfo() from the source 
packet of the beginning of AV stream file as initial value. The absolute 
address in the inside of the AV stream file is computed by SPN_xxx = 
RSPN_xxx-offset_SPN. The value of RSPN_EP_start must appear in 
ascending order in for-loop of syntax. 

[0246] Next, TU_map is explained with reference to drawing 73 . TU_map 
makes one time-axis based on the arrival timer clock (clock of the arrival time 
base) of a source packet. The time-axis is called TU_map_time_axis. The 
zero of TU_map_time_axis is shown by offseMime in TU_map(). 
TU_map_time_axis is divided into a fixed unit from offset_time. The unit is 
called time_unit. 



[0247] In each time_unit in AV stream, the address on AV stream file of the 
source packet of the first perfect form is stored in TU_map. These addresses 
are called RSPN_time_unit_start. It sets on TU_map_time_axis and is k. The 
time of day when time_unit of eye watch (k>=0) starts is called TU_start_time 
(k). This value is computed based on a degree type. 
TU_start_time (k) = offset_time+k*time^unit_sizeTU_start_time (k) has the 
precision of 45kHz. 

[0248] Drawing 74 is drawing showing the syntax of TU_map. The field of the 
32-bit length of offset_time gives the offset time to TU_map_time_axis for 
explaining the syntax of TU_map shown in drawing 74 . This value shows the 
offset time of day to time_unit of the beginning in Clip. offset_time is 
magnitude which makes a unit the 45kHz clock drawn from the arrival timer 
clock of 27MHz precision. offset_time must be set to zero when AV stream is 
recorded as new Clip. 

[0249] 32 bit fields of time_unit_size give the magnitude of time_unit, and it is 
magnitude which makes a unit the 45kHz clock drawn from the arrival timer 
clock of 27MHz precision. time_unit_size is good to make it 1 or less 
(time_unit_size<=45000) second. 32 bit fields of number_of_time_unit_entries 
show the number of entries of time_unit currently stored in TU_map(). 
[0250] 32 bit fields of RSPN_time_unit_start show the relative address of the 
location which each time_unit starts in AV stream. RSPN_time_unit_start is 
magnitude which makes a source packet number a unit, and counts the value 
of offset_SPN defined in Cliplnfo() from the source packet of the beginning of 
an AV stream file as initial value. The absolute address in the inside of the AV 
stream file is computed by SPN_xxx = RSPN_xxx-offset_SPN. The value of 
RSPN_time_unit_start must appear in ascending order in for-loop of syntax. 
(k+1) When anything does not have a source packet into time_unit of eye 
watch, RSPN_time_unit__start of eye watch (k+1) must be equal to k-th 
RS P N_ti me_u n i t_sta rt . 

[0251] ClipMark in the syntax of zzzzz.clip shown in drawing 45 is explained. 
ClipMark is the mark information about a clip and is stored into ClipMark. This 
mark is not set by the recorder (record regenerative apparatus 1), and is not 
set by the user. 



[0252] Drawing 75 is drawing showing the syntax of ClipMark. They are four 
character alphabetic characters in which version_number shows the version 
number of this ClipMark() for explaining the syntax of ClipMark shown in 
drawing 75 . version_number must be encoded with "0045" according to ISO 
646. 

[0253] length is a 32-bit unsigned integer which shows the byte count of 
ClipMark() from immediately after this length field to the last of ClipMark(). 
number_jDf_Clip_marks, the 16-bit unsigned integer which shows the number 
of the mark currently stored in ClipMark. number_of_Clip__marks You may be 
0. mark_type is the 8-bit field which shows the type of a mark, and is encoded 
according to the table shown in drawing 76 . 

[0254] mark_time_stamp is 32 bit fields and stores the time stump in which the 
point with which the mark was specified is shown. The semantics of 
markjime_siamp changes with CPLtype in PlayList(), as shown in drawing 
77 . 

[0255] When, as for STC_sequenceJd, CPIJype in CPI() shows EP_map 
type, this 8-bit field shows STC_sequence_id of the STC continuation section 
on which mark_time_stamp is put. When CPLtype in CPI() shows TU_map 
type, this 8-bit field has no semantics, but is set to zero. The 8-bit field of 
character_set shows the coding approach of the character alphabetic 
character encoded by the mark_name field. The coding approach 
corresponds to the value shown in drawing 19 . 

[0256] Eight bit fields of namejength show the cutting tool length of the mark 
name shown in the Mark_name field. The field of mark_name shows the name 
of a mark. The byte count of the left in this field to a namejength number is 
an effective character alphabetic character, and it shows the name of a mark. 
In the mark_name field, as for the value after these effective characters 
alphabetic character, what kind of value may be in close. 
[0257] The field of ref_thumbnail_index shows the information on the 
thumbnail image added to a mark. In the case of the value whose 
reMhumbnailjndex field is not OxFFFF, the thumbnail image is added to the 
mark and the thumbnail image is stored in the mark.thmb file. The image is 
referred to using the value of ref_thumbnail_index in a mark.thmb file, the 



ref_thumbnail_index field - OxFFFF it is - a case - the mark a thumbnail 
image -- adding having - **** . 

[0258] Drawing 78 is drawing showing other syntax of ClipMark replaced with 
drawing 75 , and drawing 79 shows the example of the table of markjype 
which can be set in that case and which replaces drawing 76 . the time of 
markjype showing the value of OxFF from OxCO, as for 
reserved_for_maker_ID - the — It is the 16-bit field which shows the 
manufacturer ID of the manufacturer who defines mark__type. A DVR format 
licenser specifies Manufacturer ID. mark_entry() is information which shows 
the point specified as the marking point, and the detail of the syntax is 
mentioned later. representative_picture_entry() is information which shows the 
point of the image representing the mark shown by mark_entry(), and the 
detail of the syntax is mentioned later. 

[0259] When a user reproduces AV stream, ClipMark is used in order to 
enable it to search the content visually. A DVR player uses GUI (graphical 
user interface), and shows a user the information on ClipMark. It is better to 
show the picture which representative_picture_entry() shows rather than the 
picture which mark_entry() shows, in order to display the information on 
ClipMark visually. 

[0260] The example of mark_entry() and representative_picture_entry() is 
shown in drawing 80 . For example, suppose that the program name (title) of 
the program is displayed after a certain program begins, and carrying out for a 
while (after several seconds). When making ClipMark, mark_entry() is put on 
the initiation point of the program, and you may make it put 
representative_picture_entry() on the point with which the program name (title) 
of the program is displayed. 

[0261] If a DVR player displays the image of representative_picture_entry on 
GUI and a user specifies the image, a DVR player will start playback from the 
point with which mark_entry was placed. 

[0262] mark_entry() It reaches. The syntax of representative_picture_entry() is 
shown in drawing 81 . 

[0263] mark_time_stamp is 32 bit fields, in mark_entry(), the time stump in 
which the point with which the mark was specified is shown is stored, and it 



stores the time stump in which the point of the image representing the mark 
shown by mark_entry() is shown in representative_picture_entry(). 
[0264] Next, mark_entry() in the case of using the information on the address 
base rather than using the information on the time stump base by PTS, in 
order to specify ClipMark The example of the syntax of 
representative_picture_entry() is shown in drawing 82 . 
[0265] In RSPN_ref_EP_start and mark_entry(), the relative address of the 
source packet which shows the entry point of the stream for decoding the 
picture of a marking point in AV stream is shown. Moreover, in 
representative_picture_entry(), the relative address of the source packet 
which shows the entry point of the stream for decoding the picture 
representing the mark shown by mark_entry() is shown. The value of 
RSPN_ref_EP_start must be stored as RSPN_EP_start in EP_map, and the 
value of PTS_EP_start corresponding to the RSPN_EP_start must be value 
nearest than PTS of the picture of a marking point among the past in EP_map. 
[0266] offset_num_pictures is the 32-bit field and shows the number of 
pictures of the offset to a picture shown with a marking point by the display 
order from the picture referred to by RSPN_ref_EP_start. This number is 
counted from zero. In the case of the example of drawing 83 , 
offset_num_pictures is set to 6. 

[0267] Next, mark_entry() in the case of using the information on the address 
base, in order to specify ClipMark Another example of the syntax of 
representative_picture_entry() is shown in drawing 84 . 
[0268] In mark_entry(), RSPN_mark_point shows the relative address of the 
source packet which contains the 1st byte of the access unit which the mark 
refers to in AV stream. Moreover, in representative_picture_entry(), the 
relative address of the source packet containing the 1st byte of the coding 
picture representing the mark shown by mark_entry() is shown. 
[0269] RSPN_mark_point is magnitude which makes a source packet number 
a unit, and counts the value of offset_SPN defined in Clip Information file from 
the source packet of the beginning of AV stream file as initial value. 
[0270] The relation between ClipMark and EP_map is explained using 
drawing 85 . In the case of this example, EP_map specifies 10, 11, and In as 



the address of an entry point, and presupposes that I picture which follows a 
sequence header from these addresses has begun. What is necessary is to 
read data from 11 which is the nearest entry point before the address of M1, 
and just to start, in order to be able to decode the picture started from the 
source packet, when CiipMark specifies M1 as the address of a certain mark. 
[0271] Since MakersPrivateData was already explained with reference to 
drawing 22 , the explanation is omitted. 

[0272] Next, a thumbnail information (Thumbnail Information) is explained. A 
thumbnail image is stored in a menu.thmb file or a mark.thmb file. These files 
are the same syntax structures and have only one Thumbnail(). A menu.thmb 
file stores a menu thumbnail image, i.e., the image representing Volume, and 
the image representing each PlayList. All menu thumbnails are stored only in 
one menu.thmb file. 

[0273] A mark.thmb file stores the picture showing a mark thumbnail image, 
i.e., a marking point. All the mark thumbnails to all PlayList(s) and Clip(s) are 
stored only in one mark.thmb file. Since a thumbnail is added frequently and 
deleted, add operation and actuation of partial deletion must be able to be 
easily performed at a high speed. Thumbnail() has the block structure for this 
reason. The data of an image are divided into some parts and each part is 
stored in one tn_block. One image data is stored in tn__block which ******(ed). 
tn_block which is not used may exist in the train of tnjslock. The cutting tool 
length of one thumbnail image is adjustable. 

[0274] Drawing 86 is drawing showing the syntax of menu.thmb and 
mark.thmb, and drawing 87 is drawing showing the syntax of Thumbnail in the 
syntax of menu.thmb shown in drawing 86 , and mark.thmb. They are four 
character alphabetic characters in which version_number shows the version 
number of this Thumbnail() for explaining the syntax of Thumbnail shown in 
drawing 87 . version_number must be encoded with "0045" according to ISO 
646. 

[0275] length is a 32-bit unsigned integer which shows the byte count of 
MakersPrivateData() from immediately after this length field to the last of 
Thumbnail(). tn_blocks_start_address is a 32-bit unsigned integer which 
shows the head byte address of the first tn_block by making the relative byte 



• 



count from the cutting tool of the head of Thumbnail() into a unit. A relative 
byte count is counted from zero. number_of_thumbnails is a 16-bit unsigned 
integer which gives the number of entries of the thumbnail image contained in 
ThumbnailQ. 

[0276] tn_block_size is a 16-bit unsigned integer which gives the magnitude of 
one tn_block by making 1024 bytes into a unit. For example, if it becomes 
tn_block_size=1, it shows that the magnitude of one tn_block is 1024 bytes. 
number_of_tn_blocks is a 116-bit unsigned integer showing the number of 
entries of tn_block in this ThumbnailQ. thumbnaiLindex is a 16-bit unsigned 
integer showing the index number of the thumbnail image expressed with the 
thumbnail information on the "for" loop batch which begins from this 
thumbnaiLindex field. thumbnail_index Don't carry out and don't use the value 
of OxFFFF. thumbnaiLindex Refer to for reMhumbnaiLindex in 
UlApplnfoVolumeO, UIApplnfoPlayList(), PlayListMark(), and ClipMark(). 
[0277] thumbnail_picture_format is a 8-bit unsigned integer showing a picture 
format of a thumbnail image, and takes a value as shown in drawing 88 . DCF 
and PNG in a table are allowed only within "menu.thmb." A mark thumbnail 
must take value n 0x00" (MPEG-2 Video l-picture). 

[0278] picture_data__size is a 32-bit unsigned integer which shows the cutting 
tool length of a thumbnail image per cutting tool. start_tn_block_number is a 
16-bit unsigned integer showing the tn_block number of tn_block from which 
the data of a thumbnail image begin. The head of thumbnail image data must 
be in agreement with the head of tb_block. A tn_block number begins from 0 
and is related to the value of the variable k in the "for" loop of tn_block. 
[0279] x_picture_length is a 16-bit unsigned integer showing the horizontal 
number of pixels of the frame picture frame of a thumbnail image. 
y_picture_length is a 16-bit unsigned integer showing the number of pixels of 
the perpendicular direction of the frame picture frame of a thumbnail image. 
tn_block, It is the field in which a thumbnail image is stored. All tn_block in 
Thumbnail() is the same sizes (fixed length), and the magnitude is defined by 
tn_block_size. 

[0280] Drawing 89 is drawing which meant typically how thumbnail image data 
would be stored in tn_block. Like drawing 89 , each thumbnail image data 



begins from the head of tn_block, and, in the case of the magnitude 
exceeding 1 tn_block, it is stored using continuous following tn_block. By 
doing in this way, the picture data which is variable length becomes possible 
[ managing as fixed-length data ], and can respond now by simple processing 
to edit called deletion. 

[0281] Next, AV stream file is explained. AV stream file is stored in an "M2TS" 
directory ( drawing 14 ). There are two types of AV stream files, and they are 
a Clip AV stream and a Bridge-Clip AV stream file. It must be the structure of 
a DVR MPEG-2 transport stream file where both AV streams are defined 
henceforth [ this ]. 

[0282] First, DVR MPEG-2 A transport stream is explained. The structure of a 
DVR MPEG-2 transport stream is shown in drawing 90 . AV stream file has 
the structure of a DVR MPEG 2 transport stream. A DVR MPEG 2 transport 
stream consists of Aligned unit of an integer individual, the magnitude of 
Alignedunit - 6144 Cutting tool (2048*3 cutting tool) it is . Aligned unit begins 
from the 1st byte of a source packet. A source packet is 192-byte length. One 
source packet consists of TP_extra_header and transport Paquette. 
TP_extra_header is 4-byte length and transport Paquette is 188-byte length. 
[0283] One Aligned unit consists of 32 source packets. Aligned unit of the last 
in a DVR MPEG 2 transport stream also consists of 32 source packets. 
Therefore, termination of the DVR MPEG 2 transport stream is carried out on 
the boundary of Aligned unit. When the number of transport Paquette of the 
input transport stream recorded on a disk is not a multiple of 32, a source 
packet with Nur Paquette (transport Paquette of PID=0x1FFF) must be used 
for the last Aligned unit. A file system must not add excessive information to a 
DVR MPEG 2 transport stream. 

[0284] The recorder model of a DVR MPEG-2 transport stream is shown in 
drawing 91 . The recorder shown in drawing 91 is a model on the concept for 
specifying a recording process. A DVR MPEG-2 transport stream follows this 
model. 

[0285] The input timing of an MPEG-2 transport stream is explained. An input 
MPEG 2 transport stream is a full transport stream or a partialness transport 
stream. The MPEG 2 transport stream inputted must follow ISO/IEC 13818-1 



or ISO/IEC 13818-9. The i-th cutting tool of an MPEG 2 transport stream is 
simultaneously inputted into T-STD (Transport stream system target decoder 
specified by ISO/IEC 13818-1)51, and sow spa KETTAIZA (sourse 
packetizer) 54 at time-of-day t (i). Rpk is the instant-maximum of transport 
Paquette's input rate. 

[0286] PLL52 generates 27MHz of frequencies of a 27MHz clock. The 
frequency of a 27MHz clock is locked by the value of PCR (Program Clock 
Reference) of an MPEG-2 transport stream. The arrival timer clock counter 
(arrival time clock counter) 53 is a binary counter which counts a pulse with a 
frequency of 27MHz. Arrival_time_clock (i) is the counted value of arrival time 
clockcounter53 in time-of-day t (i). 

[0287] source packetizer54 adds TP_extra_header to all transport Paquette, 
and makes a source packet. ArrivaLtime_stamp expresses the time of day 
when transport Paquette's 1st byte arrives to both T-STD51 and sow spa 
KETTAIZA 54. ArrivaLtime_stamp (k) is the sampled value of 
Arrival_time_clock (k), as shown in a degree type, and k shows transport 
Paquette's 1st byte here. 

arrival_time_stamp (k) = arrival_time_clock(k) % 230[0288] When two time 
intervals of transport Paquette inputted continuously become 230 / more than 
27 million second (about 40 seconds), the two difference of transport 
Paquette's arrival_time_stamp should be set as it has been 230 / 27 million 
seconds. It has the recorder, when becoming such. 

[0289] The smoothing buffer (smoothing buffer) 55 carries out smoothing of 
the bit rate of an input transport stream. Don't overflow the smoothing buffer 
55. Rmax is the output bit rate of the source packet from the smoothing buffer 
55 in case the smoothing buffer 55 is not empty. When the smoothing buffer 
55 is empty, the output bit rate from the smoothing buffer 55 is zero. 
[0290] Next, the parameter of the recorder model of a DVR MPEG-2 transport 
stream is explained. The value of Rmax is given by TS_recording_rate defined 
in Cliplnfo() corresponding to AV stream file. This value is computed by the 
degree type. 

The value of Rmax = TS_recording_rate * 192/188 TS_recording_rate is 
magnitude which makes bytes/second a unit. 



[0291] When an input transport stream is a SESF transport stream, Rpk must 
be equal to TS_recording_rate defined in Cliplnfo() corresponding to AV 
stream file. When an input transport stream is not a SESF transport stream, 
refer to the value defined in a descriptor, for example, 
maximum_bitrate_descriptor, partial_transport_stream_descriptor, etc. of 
MPEG-2 transport stream for this value. 

[0292] When an input transport stream is a SESF transport stream, the 
magnitude (smoothing buffer size) of the smoothing buffer 55 is zero. When 
an input transport stream is not a SESF transport stream, refer to the value 
defined in the descriptor of MPEG-2 transport stream, for example, 
smoothing_buffer_descriptor, short_smoothing_buffer_descriptor, 
partial_transport_stream_descriptor, etc. for the magnitude of the smoothing 
buffer 55. 

[0293] A record machine (recorder) and the record regenerative apparatus 1 
(player) must prepare the buffer of sufficient size, default buffer size - 1536 
bytes it is . 

[0294] Next, the player model of a DVR MPEG-2 transport stream is 
explained. Drawing 92 is drawing showing the player model of a DVR MPEG-, 
2 transport stream. This is a model on the concept for specifying 
reconstructive processing. A DVR MPEG-2 transport stream follows this 
model. 

[0295] 27 MHz X-tal (crystal oscillator)61 generates the frequency of 27MHz. 
The error range of a 27MHz frequency must be +/-30 ppm (27 million+/-810 
Hz), arrival time clock counter62 is a binary counter which counts a pulse with 
a frequency of 27MHz. arrivaLtime_clock (i) is the counted value of arrival 
time clock counter62 in time-of-day t (i). 

[0296] In smoothing buffer64, Rmax is the input bit rate of the source packet 
to the smoothing buffer 64 in case the smoothing buffer 64 is not full. When 
the smoothing buffer 64 is full, the input bit rate to the smoothing buffer 64 is 
zero. 

[0297] When arrival_time_stamp of the present source packet is equal to the 
value which is 30 bits of LSB of arrivaLtime_clock (i) for explaining the output 
timing of an MPEG-2 transport stream, transport Paquette, the source packet, 



is lured from the smoothing buffer 64. Rpk is the instant-maximum of a 
transport packet rate. Don't carry out the underflow of the smoothing buffer 64. 
[0298] About the parameter of the player model of a DVR MPEG-2 transport 
stream, it is the same as that of the parameter of the recorder model of a DVR 
MPEG-2 transport stream mentioned above. 
[0299] Drawing 93 is drawing showing the syntax of Source packet. 
transport_packet() is MPEG-2 transport Paquette specified by ISO/IEC 13818- 
1 . The syntax of TP_Extra_header in the syntax of Source packet shown in 
drawing 93 is shown in drawing 94 . It is the integer as which 
copy_permission_indicator expresses a copy limit of transport Paquette's pay 
load for explaining the syntax of TP_Extra_header shown in drawing 94 . A 
copy limit can be set to copy free, no more copy, copy once, or copy 
prohibited. Drawing 95 shows the value of copy_permission_jndicator, and the 
relation in the mode specified by them. 

[0300] copy_permissionJndicator is added to all transport Paquette. The 
value of copy_permission_indicator may be related with the value of EMI in 
IEEE1394 isochronouspacket header (Encryption Mode Indicator) when 
recording an input transport stream using an IEEE1394 digital interface. The 
value of copy_permissionJndicator may be related with the value of CCI 
embedded into transport Paquette, when recording an input transport stream 
without using an IEEE1394 digital interface. The value of 
copy_permission_indicator may be related with the value of CGMS-A of an 
analog signal when carrying out self encoding of the analog signal input. 
[0301] arrival_time_stamp is degree type arrival_time_stamp (k). In = 
arrival_time_clock(k) % 230, it is an integral value with the value specified by 
a rri va l_ti me_sta m p . 

[0302] A Clip AV stream must have [ defining a Clip AV stream and ] the 
structure of a DVR MPEG-2 transport stream where a definition which was 
mentioned above is carried out. arrival_time_clock (i) must increase 
continuously in a Clip AV stream. Even if the break point of system time base 
(STC base) exists in a Clip AV stream, arrival_time_clock (i) of the Clip AV 
stream must increase continuously. 

[0303] The maximum of the difference of the initiation in a Clip AV stream and 



arrivaLtime_clock between termination (i) must be 26 hours. This limit 
guarantees that PTS (Presentation Time Stamp) of the same value never 
appears in a Clip AV stream, when the break point of system time base (STC 
base) does not exist in an MPEG 2 transport stream. MPEG 2 systems 
specification has specified the wrap around period of PTS as 233 / 90000 
second (about 26.5 hours) . 

[0304] A Bridge-Clip AV stream must have [ defining a Bridge-Clip AV stream 
and ] the structure of a DVR MPEG-2 transport stream where a definition 
which was mentioned above is carried out. A Bridge-Clip AV stream must 
contain the break point of one arrival time base. The transport stream before 
and behind the break point of arrival time base must follow DVR-STD which 
must follow a limit of coding mentioned later and is mentioned later. 
[0305] In the gestalt of this operation, the video between Playltem(s) in edit 
and seamless connection of an audio are supported. Making between 
Playltem seamless connection guarantees "continuation supply of data", and 
"seamless decode processing" to a player/recorder. "Continuation supply of 
data" is being able to guarantee a file system supplying data with a required 
bit rate so that a decoder's may not be made to cause the underflow of a 
buffer. The real time nature of data is guaranteed, and data are stored in the 
block unit which sufficient magnitude followed so that data can be read from a 
disk. 

[0306] "Seamless decode processing" is that a player can display the audio 
video data recorded on the disk, without making the playback output of a 
decoder start a pause and a gap. 

[0307] AV stream which Playltem by which seamless connection is made 
refers to is explained. It can judge whether connection of Playltem to precede 
and the present Playltem is guaranteed to indicate by seamless from the 
connection_condition field defined in the present Playltem. The seamless 
connection between Playltem(s) has the approach of using Bridge-Clip, and 
the approach which is not used. 

[0308] Drawing 96 shows the relation between Playltem preceded in the case 
of using Bridge-Clip, and the present Playltem. In drawing 96 , the stream 
data which a player reads give a shadow and are shown. TS1 shown in 



drawing 96 consists of the stream data which were able to attach the shadow 
of Clipl (Clip AV stream), and the stream data which were able to attach the 
shadow before RSPN__arrival_time_discontinuity of Bridge-Clip. 
[0309] The stream data which were able to attach the shadow of Clipl of TS1 
are stream data from the address of a stream required in order to decode the 
presentation unit corresponding to IN_time (illustrated by IN_time1 in drawing 
96 ) of Playltem to precede to the source packet referred to by 
RSPN_exit_from_previous_Clip. The stream data which were able to attach 
the shadow before RSPN_arrival_time_discontinuity of Bridge-Clip contained 
in TS1 are stream data from the source packet of the beginning of Bridge-Clip 
to the source packet in front of the source packet referred to by 
RS P N_a rri va l_ti m e_d isco n ti n u i ty . 

[0310] Moreover, TS2 in drawing 96 consists of the stream data which were 
able to attach the shadow of Clip2 (Clip AV stream), and the stream data 
which were able to attach the shadow after RSPN_arrival_time_discontinuity 
of Bridge-Clip. The stream data which were able to attach the shadow after 
RSPN_arrivaLtime_discontinuity of Bridge-Clip contained in TS2 are stream 
data from the source packet referred to by RSPN_arrivaLtime_discontinuity to 
the source packet of the last of Bridge-Clip. The stream data which were able 
to attach the shadow of Clip2 of TS2 are stream data to the address of a 
stream required in order to decode the presentation unit corresponding to 
OUTJime (illustrated by OUT_time2 in drawing 96 ) of the present Playltem 
from the source packet referred to by RSPN_enter_to_current_Clip. 
[0311] Drawing 97 shows the relation between Playltem preceded when not 
using Bridge-Clip, and the present Playltem. In this case, the stream data 
which a player reads give a shadow and are shown. TS1 in drawing 97 
consists of the stream data which were able to attach the shadow of Clipl 
(Clip AV stream). The stream data which were able to attach the shadow of 
Clipl of TS1 begin from the address of a stream required in order to decode 
the presentation unit corresponding to IN_time (illustrated by IN_time1 in 
drawing 97 ) of Playltem to precede, and are data to the source packet of the 
last of Clipl. Moreover, TS2 in drawing 97 consists of the stream data which 
were able to attach the shadow of Clip2 (Clip AV stream). 



[0312] The stream data which were able to attach the shadow of Clip2 of TS2 
are stream data to the address of a stream required in order to begin from the 
source packet of the beginning of Clip2 and to decode the presentation unit 
corresponding to OUTJime (illustrated by OUT_time2 in drawing 97 ) of the 
present Playltem. 

[0313] In drawing 96 and drawing 97 , TS1 and T2 are the streams which the 
source packet followed. Next, a stream convention of TS1 and TS2 and the 
connection conditions between them are considered. First, the coding limit for 
seamless connection is considered. As a limit of the coding structure of a 
transport stream, the number of the programs included in TS1 and TS2 must 
be 1 first. The number of the video streams contained in TS1 and TS2 must 
be 1. The number of the audio streams contained in TS1 and TS2 must be 
two or less. The number of the audio streams contained in TS1 and TS2 must 
be equal. In TS1 and/or TS2, the elementary streams or private streams other 
than the above may be contained. 

[0314] A limit of a video bit stream is explained. Drawing 98 is drawing 
showing the example of the seamless connection shown by the display order 
of a picture. In order to be able to display a video stream seamlessly in a node, 
the unnecessary picture displayed before IN_time2 (IN_time of Clip2) the 
OUT_time1 (OUTJime of Clipl) back must be removed by the process which 
re-encodes the partial stream of Clip near a node. 
[0315] The example which makes seamless connection using 
BridgeSequence when shown in drawing 98 is shown in drawing 99 . The 
video stream of Bridge-Clip before RSPN_arrival_time_discontinuity consists 
of the coding video stream to the picture corresponding to OUT_time1 of Clipl 
of drawing 98 . And it connects with the video stream of Clipl to precede, and 
the video stream is re-encoded so that it may become the elementary stream 
which followed MPEG 2 specification by one continuation. 
[0316] Similarly, the video stream of Bridge-Clip after 

RSPN_arrival_time__discontinuity consists of the coding video stream after the 
picture corresponding to IN_time2 of Clip2 of drawing 98 . And decoding 
initiation can be carried out correctly and it connects with the video stream of 
Clip2 following this, and the video stream is re-encoded so that it may become 



the elementary stream which followed MPEG 2 specification by one 
continuation. In order to make Bridge-Clip, generally, the picture of several 
sheets must be re-encoded and the other picture can be copied from Clip of 
an original copy. 

[0317] The example which makes seamless connection without using 
BridgeSequence in the case of the example shown in drawing 98 is shown in 
drawing 100 . The video stream of Clipl consists of the coding video stream 
to the picture corresponding to OUTJimel of drawing 98 , and it is re- 
encoded so that it may become the elementary stream which followed MPEG 
2 specification by one continuation. Similarly, the video stream of Clip2 
consists of the coding video stream after the picture corresponding to 
IN_time2 of Clip2 of drawing 98 , and it is re-encoded so that it may become 
the elementary stream which followed MPEG 2 specification by one 
continuation. 

[0318] The frame rate of the video stream of TS1 and TS2 must be equal to 
explaining a coding limit of a video stream first. Termination of the video 
stream of TS1 must be carried out by sequence_end_code. The video stream 
of TS2 must be started by Sequence Header, GOP Header, and l-picture. the 
video stream of TS2 - closed one - it must start by GOP. 
[0319] The video presentation unit (a frame or field) defined in a bit stream 
must be continuation on both sides of a node. There must not be no gap of a 
frame or the field in a node. In a node, the field sequence of a top-bottom 
product must be continuation. In encoding which uses 3-2 PURUDAUN, it is 
"top_field_first". It reaches. In order to rewrite a "repeat_first_field" flag or to 
prevent generating of a field gap, you may make it re-encode locally. 
[0320] The sampling frequency of the audio of TS1 and TS2 must be the 
same as explaining a coding limit of an audio bit stream. The coding approach 
(example . MPEG1 layer 2, AC-3, SESF LPCM, AAC) of the audio of TS1 and 
TS2 must be the same. 

[0321] Next, the audio frame of the last of the audio stream of TS1 must 
contain the audio sample with display time of day equal at the time of display 
termination of the display picture of the last of TS1 in explaining a coding limit 
of an MPEG-2 transport stream. The audio frame of the beginning of the 



audio stream of TS2 must contain the audio sample with display time of day 
equal at the time of display initiation of the display picture of the beginning of 
TS2. 

[0322] In a node, a gap must not be in the sequence of an audio presentation 
unit. As shown in drawing 101 , there may be overlap defined by the die 
length of the audio presentation unit of under 2 audio frame section. The first 
Paquette who transmits the elementary stream of TS2 must be a video packet. 
The transport stream in a node must follow DVR-STD mentioned later. 
[0323] TS1 and TS2 must not contain the break point of arrival time base in 
explaining a limit of Clip and Bridge-Clip in each. 

[0324] The following limits are applied only when using Bridge-Clip. Only in 
the node of the source packet of the last of TS1 , and the source packet of the 
beginning of TS2, a Bridge-ClipAV stream has the break point of only one 
arrival time base. RSPN_arrival_time_discontinuity defined in Cliplnfo() must 
show the address of the break point, and it must show the address which 
refers to the source packet of the beginning of TS2. 

[0325] Any source packet in Clipl is sufficient as the source packet referred to 
by RSPN_exit_from_previous_Clip defined in BridgeSequencelnfo(). It does 
not need to be the boundary of Aligned unit. Any source packet in Clip2 is 
sufficient as the source packet referred to by RSPN_enter_to_current_Clip 
defined in BridgeSequencelnfo(). It does not need to be the boundary of 
Aligned unit. 

[0326] OUTJime (OUT_time1 shown in drawing 96 and drawing 97 ) of 
Playltem preceded for explaining a limit of Playltem must show the display 
end time of the video presentation unit of the last of TS1. IN_time (IN_time2 
shown in F drawing 96 and drawing 97 ) of the present Playltem must show 
the display start time of the video presentation unit of the beginning of TS2. 
[0327] Seamless connection must be made by explaining a limit of the data 
allocation in the case of using Bridge-Clip with reference to drawing 102 so 
that continuation supply of data may be guaranteed by the file system. This 
must be performed by arranging the Bridge-Clip AV stream connected to 
Clipl (ClipAV stream file) and Clip2 (Clip AV stream file) so that a data 
allocation convention may be fulfilled. 



[0328] RSPN_exit_from_previous_Clip must be chosen as the stream part of 
Clipl (Clip AV stream file) before RSPN_exit_from_previous_Clip is arranged 
to the continuation field more than half fragmentation. The data length of a 
Bridge-Clip AV stream must be chosen so that it may be arranged to the 
continuation field more than half fragmentation. RSPN_enter_to_current_Clip 
must be chosen as the stream part of Clip2 (Clip AV stream file) after 
RSPN_enter_to_current_Clip is arranged to the continuation field more than 
half fragmentation. 

[0329] Seamless connection must be made by explaining a limit of the data 
allocation in the case of making seamless connection without using Bridge- 
Clip with reference to drawing 103 so that continuation supply of data may be 
guaranteed by the file system. This must be performed by arranging the part 
of the last of Clipl (Clip AV stream file), and the part of the beginning of Clip2 
(Clip AV stream file) so that a data allocation convention may be fulfilled. 
[0330] The stream part of the last of Clipl (Clip AV stream file) must be 
arranged to the continuation field more than half fragmentation. The stream 
part of the beginning of Clip2 (Clip AV stream file) must be arranged to the 
continuation field more than half fragmentation. 

[0331] Next, DVR-STD is explained. DVR-STD is a conceptual model for 
modeling generation of a DVR MPEG 2 transport stream, and decoding in the 
case of verification. Moreover, DVR-STD is also a conceptual model for 
modeling generation of AV stream referred to by two Playltem(s) which were 
mentioned above, and by which seamless connection was made, and 
decoding in the case of verification. 

[0332] A DVR-STD model is shown in drawing 104 . The DVR MPEG-2 
transport stream player model is contained in the model shown in drawing 104 
as a component. The notation approach of of n, TBn, MBn, EBn, TBsys, Bsys, 
Rxn, Rbxn, Rxsys, Dn, Dsys, and On and Pn (k) is the same as what is 
defined as T-STD of ISO/IEC 13818-1. That is, it is as follows, n is the index 
number of an elementary stream. TBn is the transport buffer of the elementary 
stream n, and is **. 

[0333] MBn is the multiplex buffer of the elementary stream n. It exists only 
about a video stream. EBn is the elementary stream buffer of the elementary 



stream n. It exists only about a video stream. TBsys is an input buffer for the 
system information of the program under decode. Bsys is a main buffer in the 
system target decoder for the system information of the program under 
decode. Rxn is a transmission rate by which data are removed from TBn. 
Rbxn is a transmission rate by which a PES Paquette pay load is removed 
from MBn. It exists only about a video stream. 

[0334] Rxsys is a transmission rate by which data are removed from TBsys. 
Dn is the decoder of the elementary stream n. Dsys is a decoder about the 
system information of the program under decode. On is re-ordering buffer of 
the video stream n. Pn (k) is the k-th presentation unit of the elementary 
stream n. 

[0335] The decoding process of DVR-STD is explained. While reproducing the 
single DVR MPEG-2 transport stream, the timing which inputs transport 
Paquette into the buffer of TB1 , TBn, or TBsys is determined by 
arrivaLtime_stamp of a source packet. The convention of buffering actuation 
of TB1, MB1, EB1, TBn, Bn, TBsys, and Bsys is the same as T-STD specified 
to ISO/IEC 13818-1. A convention of decode actuation and a display action is 
the same as T-STD specified to ISO/IEC 13818-1. 

[0336] A decoding process while reproducing Playltem by which seamless 
connection was made is explained. Here, playback of two AV streams 
referred to by Playltem by which seamless connection was made will be 
explained, and future explanation explains the playback of TS (for example, 
shown in drawing 96 )1, and TS2 mentioned above. TS1 is a stream to 
precede and TS2 is a current stream. 

[0337] Drawing 105 shows the timing chart of the input of transport Paquette 
when moving from a certain AV stream (TS1) to the following AV stream 
(TS2) seamlessly connected to it, decode, and a display. While moving from 
predetermined AV stream (TS1) to the following AV stream (TS2) seamlessly 
connected to it, the time-axis ( drawing 105 is shown by ATC2) of the arrival 
time base of TS2 is not the same as the time-axis ( drawing 105 is shown by 
ATC1) of the arrival time base of TS1 . 

[0338] Moreover, the time-axis ( drawing 105 is shown by STC2) of the 
system time base of TS2 is not the same as the time-axis ( drawing 105 is 



shown by STC1) of the system time base of TS1 . It is required that the display 
of video should continue seamlessly. Overlap may be shown in the display 
time of the presentation unit of an audio. 

[0339] DVR-STD Input timing is explained. It is TB1 and TBn of DVR-STD 
until the time amount by time of day T1 , i.e., the video packet of the last of 
TS1 , carries out input termination at TB1 of DVR-STD. Or the input timing to 
the buffer of TBsys is determined by arrivaLtime_stamp of the source packet 
of TS1. 

[0340] Remaining Paquette of TS1 must be inputted into the buffer of TBn of 
DVR-STD, or TBsys with the bit rate of TS_recording_rate (TS1). Here, 
TS_recording_rate (TS1) is the value of TS_recording_rate defined in 
Cliplnfo() corresponding to Clipl . The time of day which the cutting tool of the 
last of TS1 inputs into a buffer is time of day T2. Therefore, 
arrival_time_stamp of a source packet is disregarded in the section from time 
of day T1 to T2. 

[0341] If N1 is made into the byte count of transport Paquette of TS1 following 
the video packet of the last of TS1 , time of day T1 thru/or the time amount DT 
1 to T2 will be time amount required in order that 1 byte of N may carry out 
input termination with the bit rate of TS_recording_rate (TS1), and will be 
computed by the degree type. 

deltaT1=T2-T1=N1 / TS_record in gyrate Both the values of RXn and RXsys 
change to the value of TS_recording_rate (TS1) before time of day (TS1) T1 
thru/or T2. The buffering actuation of those other than this rule is the same as 
T-STD. 

[0342] arrival time clock counter is reset by the value of arrivaLtime_stamp Q f 
the source packet of the beginning of TS2 in the time of day of T2. TB1 of 
DVR-STD, and TBn Or the input timing to the buffer of TBsys is determined 
by arrivaLtime_stamp of the source packet of TS2. RXn and RXsys both 
change to the value defined in T-STD. 

[0343] In addition to the amount of buffers defined by T-STD, an audio 
decoder and a system decoder need the additional amount of buffers (amount 
of data for about 1 second) to explain additional audio buffering and system 
data buffering so that the input data of the section from time of day T1 to T2 



can be processed. 

[0344] The display of a video presentation unit must let a node pass to explain 
the presentation timing of video, and it must be continuation without a gap. 
Here, STC1 considers as the time-axis (in drawing 105 , illustrated with STC1) 
of the system time base of TS1 , and STC2 is the time-axis (in drawing 97 , 
illustrated with STC2.) of the system time base of TS2. In accuracy, PCR of 
the beginning of TS2 starts STC2 from the time of day inputted into T-STD. It 
carries out. 

[0345] The offset between STC1 and STC2 is determined as follows, end is 
PTS on PTS1STC1 corresponding to the video presentation unit of the last of 
TS1, PTS2start is PTS on STC2 corresponding to the video presentation unit 
of the beginning of TS2, and if Tpp considers as the display period of the 
video presentation unit of the last of TS1, offset STC_delta between two 
system time base will be computed by the degree type. 
STC_delta = PTS1end+Tpp-PTS2start [0346] Explaining the timing of the 
presentation of an audio may have the overlap of the display timing of an 
audio presentation unit in a node, and they are 0 thru/or under 2 audio frame 
(see "audio overlap" currently illustrated in drawing 105 ). Which audio sample 
being chosen and carrying out resynchronization of the display of an audio 
presentation unit to the time base where it was amended after the node are 
set up by the player side. 

[0347] In time of day T5, the audio presentation unit of the last of TS1 is 
displayed for explaining about the system time clock of DVR-STD. The 
system time clock may overlap among T5 from time of day T2. In this section, 
DVR-STD changes a system time clock between the value (STC1) of old time 
base, and the value (STC2) of new time base. The value of STC2 is 
computed by the degree type. 

STC2=STC1-STC_delta [0348] The continuity of buffering is explained. 
STC1 1 video_end is the value of STC on the system time base STC 1 in case 
the cutting tool of the last of the video packet of the last of TS1 arrives to TB1 
of DVR-STD. STC22 video_start is the value of STC on the system time base 
STC 2 in case the cutting tool of the beginning of the video packet of the 
beginning of TS2 arrives to TB1 of DVR-STD. STC21 video_end is STC1 1 



videcLend. It is the value which converted the value into the value on the 
system time base STC 2. STC21 video_end is computed by the degree type. 
STC21 video_end = STC1 1 video_end -STC_delta [0349] In order to follow 
DVR-STD, it is required that the following two conditions should be fulfilled. 
First, the arrival timing to TB1 of the video packet of the beginning of TS2 
must fill the inequality shown below. And the inequality shown below must be 
filled. 

STC22 video_start > STC21 video_end+ deltaTI - this inequality is filled - as 
- Clipl - and - or the partial stream of Clip2 ~ re-encoding - and -- or when 
it is necessary to re-multiplex, it is carried out if needed [ that ]. 
[0350] next, the input of the video packet from TS2 which continues at the 
input of the video packet from TS1 , and it on the time-axis of the system time 
base which converted STC1 and STC2 on the same time-axis - a video 
buffer — overflow — and don't carry out an underflow. 
[0351] The content of the data currently recorded on the record medium, 
playback information, etc. can be managed appropriately, and it has them, 
and a user can check the content of the data currently recorded on the record 
medium appropriately at the time of playback, or it can make it possible to 
reproduce desired data simple by being based on such syntax, DS, and a 
regulation. 

[0352] In addition, although the gestalt of this operation makes an MPEG 2 
transport stream an example and explains it as a multiplexing stream, it can 
be applied also about the DSS transport stream currently used with DirecTV 
service (trademark) of not only this but an MPEG 2 program stream, or the 
U.S. 

[0353] Next, the syntax of mark_entry() and representative_picture_entry() 
explains the processing in the case of performing search playback of a scene 
shown with the marking point in the case of being a configuration as shown in 
drawing 81 with reference to the flow chart of drawing 106 . 
[0354] In step S1, the control section 23 of the record regenerative apparatus 
1 first reads EP_Map ( drawing 70 ), STCJnfo ( drawing 52 ) and 
Programjnfo ( drawing 54 ) which are the data dace of a DVR transport 
stream file, and ClipMark ( drawing 78 ) from a record medium 100. 



[0355] In step S2, a control section 23 creates the list of thumbnails from the 
picture referred to by representative_picture_entry ( drawing 81 ) of ClipMark 
( drawing 78 ), or ref_thumbnail_index, outputs it from the terminal 24 as user 
interface I/O, and is displayed on the menu screen of GUI. In this case, 
priority is given to ref_thumbnail_index over representative_picture_entry 
when refJhumbnaiLindex has an effective value. 

[0356] In step S3, a user specifies the marking point of a playback start point. 
This is performed because a user chooses a thumbnail image from the inside 
on the menu screen displayed as GUI. A control section 23 acquires the 
marking point matched with the specified thumbnail corresponding to this 
selection actuation. 

[0357] In step S4, a control section 23 acquires STC_sequence_id with PTS 
of mark_time_stamp of mark_entry ( drawing 81 ) specified at step S3. 
[0358] In step S5, a control section 23 acquires the source packet number 
which the STC time-axis corresponding to STC_sequence_id acquired by step 
S4 starts from STCJnfo ( drawing 52 ). 

[0359] In step S6, a control section 23 acquires a source packet number with 
the nearest entry point (I picture) from PTS of the Paquette number which the 
STC time-axis acquired at step S5 starts, and the marking point acquired by 
step S4, before being more nearly time than PTS of a marking point. 
[0360] A control section 23 reads the data of a transport stream, and is made 
to supply them to the AV decoder 27 in step S7 from a source packet number 
with the entry point acquired at step S6. 

[0361] A control section 23 controls the AV decoder 27, and makes a display 
start in step S8 from the picture of PTS of the marking point acquired by step 
S4. 

[0362] The above actuation is further explained with reference to drawing 107 
thru/or 109. 

[0363] Now, a DVR transport stream file has the STC time-axis of 
STC_sequence_id=idO, and let the source packet number which the time-axis 
starts be a thing smaller than the source packet number of the scene start 
point A as shown in drawing 107 . And CM (commercials) shall be inserted in 
from the source packet number B before C. 



[0364] As shown in drawing 108 , at this time, each PTS is registered into 
EP_Map corresponding to EP_Map shown in drawing 70 as PTS (A), PTS (B), 
and PTS (C) as PTS_EP_start corresponding to A, B, and C which are shown 
by RSPN_EP_start. 

[0365] Moreover, as shown in drawing 109 , as shown in drawing 109 , 
corresponding to the value of a scene start, CM start and the mark type 
( drawing 79 ) 0x92 showing CM end, 0x94, and 0x95, mark_entry and 
representative_picture_entry are recorded on ClipMark corresponding to 
ClipMark of drawing 78 . 

[0366] As Mark_Time_stamp of mark_entry, corresponding to the scene start, 
CM start, and CM end, PTS (a1), PTS (bO), and PTS (cO) are registered, 
respectively, and each of each STC_sequence_id is set to idO. 
[0367] Similarly, as Mark_Time_stamp of Representative_picture_entry, 
corresponding to the scene start, CM start, and CM end, PTS (a2), PTS (b0), 
and PTS (cO) are registered, respectively, and, as for each of them, 
STC_sequence_id is set to idO. 

[0368] In PTS(A) < PTS (a1), in step S6, the Paquette number A is acquired, 
the transport stream which begins from the Paquette number A is supplied to 
the AV decoder 27 in step S7, and a display is started from the picture of PTS 
(a1) in step S8. 

[0369] Next, with reference to the flow chart of drawing 110 , the syntax of 
mark_entry and representative_picture_entry explains processing of CM skip 
playback in the case of being a configuration as shown in drawing 81 with 
reference to the flow chart of drawing 110 . 

[0370] In step S21 , a control section 23 reads EP_map ( drawing 70 ), 
STCJnfo ( drawing 52 ), Programjnfo ( drawing 54 ), and ClipMark ( drawing 
78 ) from a record medium 100. In step S22, a user specifies CM skip 
playback from the terminal 24 as user interface I/O. 

[0371] In step S23, a control section 23 acquires PTS of the mark information 
whose mark type ( drawing 79 ) is CM start point (0x94), PTS of the mark 
information which is a point (0x95) ending [ CM ], and STC_sequence_id 
corresponding to a list ( drawing 81 ). 

[0372] In step S24, a control section 23 acquires the source packet number 



which the STC time-axis corresponding to STC_sequence_id of CM start point 
and an ending point starts from STCJnfo ( drawing 52 ). 
[0373] A control section 23 carries out reading appearance of the transport 
stream from a record medium 100, supplies it to the AV decoder 27, and 
makes decoding start in step S25. 

[0374] In step S26, as for a control section 23, a current display image 
investigates whether it is the image of PTS of CM start point. When a current 
display image is not an image of PTS of CM start point, it progresses to step 
S27 and, as for a control section 23, the display of an image is continued. 
Then, as for processing, return and processing after it are repeatedly 
performed by step S25. 

[0375] In step S26, when judged with a current display image being an image 
of PTS of CM start point, it progresses to step S28, and a control section 23 
controls the AV decoder 27, and stops decoding and a display. 
[0376] Next, in step S29, a control section 23 acquires the Paquette number 
which the STC time-axis corresponding to STC_sequence_id of the point 
ending [ CM ] starts, and before being more nearly time than PTS of the point, 
it acquires a source packet number with the nearest entry point from the 
Paquette number and PTS of the point acquired by processing of step S23 
ending [ CM ]. 

[0377] A control section 23 reads the data of a transport stream, and is made 
to supply them to the AV decoder 27 in step S30 from a source packet 
number with the entry point acquired by processing of step S29. 
[0378] A control section 23 controls the AV decoder 27, and makes a display 
resume from the picture of PTS of the point ending [ CM ] in step S31 . 
[0379] If the above actuation is further explained with reference to Fic^ 107 
thru/or 109 , in the case of this example, CM start point and the point ending 
[ CM ] exist on a common STC time-axis called STC_sequence_id=idO, and 
let the source packet number which that STC time-axis starts be a thing 
smaller than the source packet number A of the start point of a scene. 
[0380] A transport stream is decoded, and a display is suspended by the AV 
decoder 27 when judged with display time of day having been set to PTS (bO) 
at step S26 (when judged with it being CM start point). And in PTS(C) <PTS 



(cO), at step S30, decoding is resumed from the stream which begins from the 
data of the Paquette number C, and a display is resumed from the picture of 
PTS (cO) in step S31. 

[0381] In addition, this approach can be applied, not only CM skip playback 
but when skipping the scene for two points generally specified by ClipMark 
and reproducing. 

[0382] Next, mark_entry and representative_picture_entry explain search 
regeneration of CM shown with the marking point in the case of being the 
syntax structure shown in drawing 82 with reference to the flow chart of 
drawing 112 . 

[0383] In step S41, a control section 23 acquires the information on EP_map 
( drawing 70 ), STCJnfo ( drawing 52 ), Programjnfo ( drawing 54 ), and 
ClipMark ( drawing 78 ). 

[0384] next, a control section 23 generates the list of thumbnails from the 
picture referred to by representative_picture_entry ( drawing 82 ) or 
reMhumbnailJndex contained in ClipMark ( drawing 78 ) which carried out 
reading appearance at step S41, and is made to display it on the menu 
screen of GUI in step S42 Priority is given to ref_thumbnail_index over 
representative_picture_entry when reMhumbnaiLindex has an effective value. 
[0385] In step S43, a user specifies the marking point of a playback start point. 
This assignment is performed by specifying the marking point in which a user 
chooses a thumbnail image, is matched with that thumbnail, and is from the 
inside on the menu screen displayed by processing of step S42. 
[0386] In step S44, a control section 23 acquires RSPN_ref_EP_start and 
offset_num_pictures ( drawing 82 ) of a marking point which were specified by 
processing of step S43. 

[0387] A control section 23 reads the data of a transport stream from the 
source packet number corresponding to RSPN_ref_EP_start acquired at step 
S44, and is made to supply them to the AV decoder 27 in step S45. 
[0388] A control section 23 makes a display start from the picture in step S46, 
when the AV decoder 27 is controlled, the picture which should be displayed 
(without) is counted up from the picture referred to by RSPN_refJEP_start and 
counted value becomes offset_num_pictures. 



[0389] The above processing is further explained with reference to Fig. 113 
thru/or 115 . In this example, the scene has started the DVR transport stream 
file from the source packet number A, and CM is inserted from the source 
packet number B to the source packet C. For this reason, as shown in 
drawing 114 , corresponding to A, B, and C as RSPN_EP_start, PTS (A), PTS 
(B), and PTS (C) are registered into EP_map as PTS_EP_start. 
[0390] Moreover, as shown in drawing 115 , mark_entry and 
representative_picture_entry are registered corresponding to the scene start, 
CM start, and the mark type of CM end. Corresponding to the scene start, CM 
start, and CM end, as RSPN_ref_EP_start, A, B, and C are registered into 
mark_entry, respectively, and M1, N1, and N2 are registered into it as 
offset„num_pictures. Similarly, as RSPN_ref„EP_start, corresponding to the 
scene start, CM start, and CM end, A, B, and C are registered into 
representative_picture_entry, respectively, and M2, N1, and N2 are registered 
into it as offset_num_pictures, respectively. 

[0391] When it **** from the picture which is in charge of a scene start, and it 
is ordered in playback, and decoding is started from the stream which begins 
from the data of the Paquette number A, the picture which should be 
displayed from the picture of PTS (A) (without it displays) is counted up and 
offset_num_pictures becomes the value of M1, a display is started from the 
picture. 

[0392] Furthermore, the syntax of mark_entry and 

representative_picture_entry explains processing of CM skip playback in the 
case of being the configuration shown in drawing 82 with reference to the flow 
chart of drawing 116 . 

[0393] In step S61, a control section 23 acquires the information on EP_map 
( drawing 70 ), STCJnfo ( drawing 52 ), Programjnfo ( drawing 54 ), and 
ClipMark ( drawing 78 ). 

[0394] In step S62, if a user orders it CM skip playback, in step S63, a control 
section 23 will acquire RSPN_ref_EP_START and offset_num_pictures 
( drawing 82 ) as mark information of each point whose mark types ( drawing 
79 ) are CM start point and a point ending [ CM ]. And the data of CM start 
point are made into RSPNLref_EP_start (1) and offset_num_pictures (1), and 



the data of the point ending [ CM ] are made into RSPN_ref_EP_start (2) and 
offset_num_pictures (2). 

[0395] In step S64, a control section 23 acquires PTS corresponding to 
RSPN_ref_EP_start (1) and RSPN_ref_EP_start (2) from EP_map ( drawing 
70). 

[0396] A control section 23 carries out reading appearance of the transport 
stream from a record medium 100, and is made to supply to the AV decoder 
27 in step S65. 

[0397] In step S66, a control section 23 judges whether a current display 
image is the picture of PTS corresponding to RSPN_ref_EP_start (1), when a 
current display image is not the picture of PTS corresponding to 
RSPN_ref_EP_start (1), progresses to step S67 and displays a picture 
continuously as it is. Then, as for processing, return and processing after it 
are repeatedly performed by step S65. 

[0398] In step S66, when it judges that a current display image is the picture 
of PTS corresponding to RSPN_ref_EP_start (1), it progresses to step S68, 
and a control section 23 stops a display, when the AV decoder 27 is 
controlled, the picture displayed from the picture of PTS corresponding to 
RSPN_ref_EP_start (1) is counted up and counted value becomes 
offset_num_pictures (1). 

[0399] A control section 23 reads the data of a transport stream from the 
source packet number of RSPN_ref_EP_start (2), and is made to supply them 
to the AV decoder 27 in step S69. 

[0400] A control section 23 makes a display start from the picture in step S70, 
when the AV decoder 27 is controlled, the picture which should be displayed 
from the picture of PTS corresponding to RSPN_ref_EP_start (2) (without it 
displays) is counted up and counted value becomes offset„num_pictures (2). 
[0401] If the above actuation is further explained with reference to Fig. 113 
thru/or 115 , the time of day PTS corresponding to the Paquette numbers B 
and C (B) and PTS (C) will be first obtained based on EP_map ( drawing 114 ). 
And when Clip AV stream is decoded and display time of day is set to PTS (B), 
a display picture counts up from the picture of PTS (B), and a display is 
suspended when the value is set to N1 ( drawing 115 ). 



[0402] Furthermore, decoding is resumed from the stream which begins from 
the data of the Paquette number C, and when the picture which should be 
displayed from the picture of PTS (C) (without it displays) is counted up and 
the value is set to N2 ( drawing 115 ), a display is resumed from the picture. 
[0403] The above processing can be applied, not only CM skip playback but 
when making the scene for two points specified by ClipMark skip and 
reproducing. 

[0404] Next, the syntax of mark_entry and representative_picture_entry 
explains search regeneration of the scene shown with the marking point in the 
case of being a configuration as shown in drawing 84 with reference to the 
flow chart of drawing 118 . 

[0405] The information on ClipMark ( drawing 78 ) is acquired by EP_map 
( drawing 70 ), STCJnfo ( drawing 52 ), Programjnfo ( drawing 54 ), and the 
list in step S81. 

[0406] A control section 23 generates the list of thumbnails from the picture 
referred to by representative_picture_entry or reMhumbnaiUndex of ClipMark 
( drawing 78 ), and is made to display it as a menu screen of GUI in step S82. 
Priority is given to reMhumbnaiUndex over representative_picture_entry 
when reMhumbnaiUndex has an effective value. 

[0407] In step S83, a user specifies the marking point of a playback start point. 
A user chooses a thumbnail image from the inside for example, on a menu 
screen, and this assignment is performed by specifying the marking point 
matched with that thumbnail. 

[0408] In step S84, a control section 23 acquires RSPI\L_mark_point ( drawing 
84 ) of mark_entry specified by the user. 

[0409] In step S85, a control section 23 is before RSPN_mark_point of a 
marking point, and acquires the nearest source packet number of an entry 
point from EP_map ( drawing 70 ). 

[0410] A control section 23 reads the data of a transport stream from the 
source packet number corresponding to the entry point acquired at step S85, 
and is made to supply them to the AV decoder 27 in step S86. 
[041 1] A control section 23 controls the AV decoder 27, and makes a display 
start in step S87 from the picture referred to by RSPN_mark_point. 



[0412] The above processing is further explained with reference to Fic^ 119 
thru/or 121^ . In this example, a DVR transport stream file carries out a scene 
start by the source packet A, and CM is inserted from the source packet 
number B to C. For this reason, corresponding to A, B, and C as 
RSPN_EP_start, PTS_EP_start is registered into EP_map of drawing 120 as 
PTS (A), PTS (B), and PTS (C), respectively, moreover, ClipMark shown in 
drawing 121 - a scene start, CM start, and CM - and - alike - corresponding 
- as RSPN_mark_point of markentry - a1 , b1 , and c1 - moreover, a2, b1 , 
and c1 are registered as RSPN_mark_point of representative_picture_entry, 
respectively. 

[0413] When ****(ing) and reproducing from the picture which is in charge of a 
scene start, if Paquette number A<a1, decoding will be started from the 
stream which begins from the data of the Paquette number A, and a display 
will be started from the picture corresponding to the source packet number a1. 
[0414] Next, the syntax of mark_entry and representative_picture_entry 
explains processing of CM skip playback in the case of being a configuration 
as shown in drawing 84 with reference to the flow chart of drawing 122 and 
drawing 123 . 

[0415] In step S101, a control section 23 acquires the information on ClipMark 

( drawing 70 ) in EP_map ( drawing 70 ), STCJnfo ( drawing 52 ), 

Programjnfo ( drawing 54 ), and a list. 

[0416] In step S102, a user specifies CM skip playback. 

[0417] In step S103, a control section 23 acquires RSPN_mark_point 

( drawing 84 ) of the mark information of each point whose mark types 

( drawing 79 ) are CM start point and a point ending [ CM ]. And a control 

section 23 makes the data of CM start point RSPN_mark_point (1), and 

makes the data of the point ending [ CM ] RSPN_mark_point (2). 

[0418] A control section 23 carries out reading appearance of the transport 

stream from a record medium 100, and the AV decoder 27 is made to output 

and decode it in step S104. 

[0419] In step S105, a control section 23 judges whether a current display 
image is a picture corresponding to RSPN_mark_point (1), when a current 
display image is not a picture corresponding to RSPN_mark_point (1), 



progresses to step S106 and displays a picture continuously as it is. Then, as 
for processing, return and processing after it are repeatedly performed by step 
S104. 

[0420] In step S105, when it judges that a current display image is a picture 
corresponding to RSPN_mark_point (1), it progresses to step S107, and a 
control section 23 controls the AV decoder 27, and stops decoding and a 
display. 

[0421] Next, in step S108, the source packet number which is before 
RSPN_mark_point (2) and has the nearest entry point is acquired from 
EP_map ( drawing 70 ). 

[0422] A control section 23 reads the data of a transport stream from the 
source packet number corresponding to the entry point acquired at step S108, 
and is made to supply them to the AV decoder 27 in step S109. 
[0423] A control section 23 controls the AV decoder 27, and makes a display 
resume in step S1 10 from the picture referred to by RSPN_mark_point (2). 
[0424] A display is suspended, when the example of Fig. 119 thru/or 121 
explained the above processing further, and Clip AV stream is decoded, it 
goes and it becomes a display picture corresponding to the source packet 
number b1 ( drawing 121 ). And when it was the source packet number C< 
source packet number c1, and decoding is resumed and it becomes a picture 
corresponding to the source packet number d from the stream which begins 
from the data of the Paquette number C, a display is resumed from the picture. 
[0425] As shown in drawing 124 as mentioned above, on PlayList, a position 
can be specified with a time stump, this time stump can be changed into a 
data address in Clip Information of each Clip, and the position of Clip AV 
stream can be accessed. 

[0426] If a user specifies a bookmark and a resume point as a time stump on 
a time-axis as PlayListMark on PlayList as shown in drawing 125 , when 
reproducing, the PlayList can use ClipMark of Clip which the PlayList is 
referring to, and, more specifically, can be accessed at the scene start point 
and the point ending [ scene ] of Clip AV stream. 

[0427] In addition, the syntax of ClipMark is changed to the example of 
drawing 78 , and can be shown in drawing 126 . 



[0428] RSPN_mark is changed and inserted in reserved_for_MakerlD, 
mark_entry(), and represetative_picture_entry() of drawing 78 in this example. 
The 32-bit field of this RSPN jnark shows the relative address of the source 
packet which contains the 1st byte of the access unit which that mark refers to 
on AV stream file. RSPN_mark is magnitude which makes a source packet 
number a unit, is defined in Clip Information file from the source packet of the 
beginning of AV stream file, and counts the value of offset_SPN as initial 
value. 

[0429] Other configurations are the same as that of the case in drawing 78 . 
[0430] The syntax of ClipMark can also be constituted as further shown in 
drawing 127 . In this example, RSPN_ref_EP_start and offset_num_pictures 
are inserted instead of RSPNjnark in drawing 126 . These are the same as 
that of the case where it is shown in drawing 82 . 

[0431] Drawing 128 is a flow chart explaining the creation of ClipMark of 
syntax shown in drawing 81 , when encoding and recording an analog AV 
signal. It explains referring to the block diagram of the record regenerative 
apparatus 1 of drawing 1 . In step S200, the analysis section 14 analyzes the 
input AV signal from terminals 1 1 and 12, and detects the focus. The focus 
specifies the characteristic scene resulting from the content of the AV stream, 
for example, is a head broth point, a point changing [ scene ], etc. of a 
program. 

[0432] Step S201 sets and a control section 23 acquires PTS of the image of 
the focus. In step S202, a control section 23 stores the information on the 
focus in ClipMark. Specifically, the information explained by the syntax and 
semantics of ClipMark of this operation is stored. [ of a gestalt ] In step S203, 
Clip Information file and Clip AV stream file are recorded on a disk. 
[0433] Drawing 129 is a flow chart explaining the creation of ClipMark of 
syntax shown in drawing 81 , when recording the transport stream inputted 
from the digital interface. It explains referring to the block diagram of the 
record regenerative apparatus 1 of drawing 1 . In step S211, a demultiplexer 
26 and a control section 23 acquire the elementary stream PID of the program 
to record. When there are two or more elementary streams for analysis, all the 
elementary streams PID are acquired. 



[0434] At step S212, a demultiplexer 26 separates an elementary stream from 
the program of the transport stream inputted from a terminal 13, and the AV 
decoder 27 decodes it to AV signal. In step S213, the analysis section 14 
analyzes the above-mentioned AV signal, and detects the focus. 
[0435] In step S214, a control section 23 acquires PTS of the image of the 
focus, and STC-sequence-id of STC to which it belongs. At step S215, a 
control section 23 stores the information on the focus in ClipMark. Specifically, 
the information explained by the syntax and semantics of ClipMark in the 
gestalt of this operation is stored. 

[0436] In step S216, Clip Information file and Clip AV stream file are recorded 
on a disk. 

[0437] It carries out like the flow chart shown in drawing 128 , and the flow 
chart shown in drawing 129 , and ClipMark which stores the mark indicating 
the characteristic image in AV stream file, i.e., a Clip AV stream file, is 
recorded, the management information data file, i.e., the Clip Information file, 
of said AV stream. 

[0438] Drawing 130 is a flow chart explaining creation of Real PlayList. It 
explains referring to the block diagram of the record regenerative apparatus 1 
of drawing 1 . In step S221, a control section 23 records a Clip AV stream. In 
step S222, a control section 23 creates PlayListQ which consists of Playltem 
which covers all the refreshable range of Above Clip. An STC break point is in 
Clip, and when PlayList() consists of two or more Playltem(s), 
connection_condition between Playltem(s) is also determined. 
[0439] In step S223, a control section 23 creates UIApplnfoPlayList(). In step 
S224, a control section 23 creates PlayListMark. In step S225, a control 
section 23 creates MakersPrivateData. In step S226, a control section 23 
records a Real PlayList file. 

[0440] Thus, whenever it records a Clip AV stream newly, one Real PlayList 
file is made. 

[0441] Drawing 131 is a flow chart explaining creation of Virtual PlayList. In 
step S231, it lets a user interface pass and playback of one Real PlayList 
currently recorded on the disk is specified. And out of the playback range of 
the Real PlayList, it lets a user interface pass and the playback section shown 



with IN point and an OUT point is specified. 

[0442] In step S232, a control section 23 judges whether all assignment 
actuation of the playback range by the user was completed. In step S232, 
when it is judged that assignment actuation of the playback range by the user 
is not ended yet, return and processing after it are repeated by step S231, 
and when it is judged that it ended, it progresses to step S233. 
[0443] In step S233, a user is determined through a user interface or the 
connection condition (connection_condition) during the two playback sections 
reproduced continuously is determined by the control section 23. In step S234, 
it lets a user interface pass and a user specifies subpass (audio for 
postrecording) information. When a user does not create subpass, the 
processing in step S234 is skipped. 

[0444] In step S235, a control section 23 creates PlayList() based on the 
playback range information specified by a user, and connection_condition. In 
step S236, a control section 23 creates UIApplnfoPlayList(). In step S237, a 
control section 23 creates PlayListMark. In step S238, a control section 23 
creates MakersPrivateData. A control section 23 makes a Virtual PlayList file 
record on a disk in step S239. 

[0445] Thus, the playback section which a user wants to see is chosen from 
the playback range of Real PlayList currently recorded on the disk, and one 
Virtual PlayList file is created for every thing which carried out grouping of the 
playback section. 

[0446] Drawing 132 is a flow chart explaining playback of PlayList. It explains 
referring to the block diagram of the record regenerative apparatus 1 of 
drawing 1 . In step S241, a control section 23 acquires the information on 
Info.dvr, Clip Information file, PlayList file, and a thumbnail file, creates the 
GUI screen in which the list of PlayList currently recorded on the disk is 
shown, lets a user interface pass, and displays it on GUI. 
[0447] In step S242, it lets a user interface pass and a user directs playback 
of one PlayList to a control section 23. In step S243, a control section 23 
acquires the source packet number which has the nearest entry point in front 
in time than IN_time from STC-sequence-id of current Play Item, and PTS of 
IN_time. In step S244, a control section 23 reads the data of AV stream from 



a source packet number with the above-mentioned entry point, and supplies 
them to the AV decoder 27. 

[0448] When playback of Playltem is before in time [ of Above Playltem ], in 
step S245, a control section 23 controls to perform connection processing of 
the display with the Playltem according to connection_condition. In step S246, 
the AV decoder 27 starts a display from the picture of PTS of IN_time. 
[0449] In step S247, the AV decoder 27 decodes AV stream continuously. In 
step S248, as for a control section 23, the image of a current display judges 
whether it is the image of PTS of OUTJime. In step S248, the image of a 
current display progresses to step S250, when it is judged that it is the image 
of PTS of OUTJime, and when it is judged that it is not the image of PTS, it 
progresses to step S249. 

[0450] In step S249, processing for displaying the image judged to be the 
image of PTS is performed, and return and processing after it are repeated by 
step S247 after that. On the other hand, in step S250, it is judged for current 
Playltem by the control section 23 in PlayList whether it is the last Playltem. In 
step S250, processing of the flow chart shown in drawing 132 when it was 
judged that current Playltem is the last Playltem in PlayList is ended, and 
when it is judged that it is not the last Playltem, return and processing after it 
are repeated by step S243. 

[0451] Drawing 133 is a flow chart explaining creation of PlayListMark. It 
explains referring to the block diagram of the record regenerative apparatus 1 
of drawing 1 . In step S261, a control section 23 acquires the information on 
Info.dvr, Clip Information file, PlayList file, and Thumbnail file, creates the GUI 
screen in which the list of PlayList currently recorded on the disk is shown, 
lets a user interface pass, and displays it on GUI. 

[0452] In step S262, it lets a user interface pass and playback of one PlayList 
is directed to a control section 23 by the user. In step S263, the playback 
section 3 starts playback of directed PlayList (carried out as explained with 
reference to the flow chart of drawing 132 ). 

[0453] In step S264, it lets a user interface pass and the set of a mark is 
directed to a control section 23 by the user at the place of a favorite scene. In 
step S265, a control section 23 acquires PTS of a mark, and Playltemjd of 



Playltem to which it belongs. 

[0454] In step S266, a control section 23 stores the information on a mark in 
PlayListMarkQ. In step S267, a PlayList file is recorded on a disk. 
[0455] Thus, PlayListMark which stores the mark which shows the Resume 
point when reproducing the marking point which the user specified out of the 
playback range of PlayList, or its PlayList is recorded on a PlayList file. 
[0456] Drawing 134 is a flow chart explaining the head broth playback for 
which ClipMark of Clip which PlayListMark and its PlayList refer to was used, 
when PlayList is reproduced. The syntax of ClipMark() shall be shown in 
drawing 81 . It explains referring to the block diagram of the record 
regenerative apparatus 1 of drawing 1 . 

[0457] In step S271, a control section 23 acquires the information on Info.dvr, 
Clip Information file, PlayList file, and Thumbnail file, creates the GUI screen 
in which the list of PlayList currently recorded on the disk is shown, lets a user 
interface pass, and displays it on GUI. 

[0458] In step S272, it lets a user interface pass and playback of one PlayList 
is directed by the user. In step S273, a control section 23 displays a user 
interface on GUI through the list of thumbnails generated from the picture 
referred to by PlayListMark and ClipMark of Clip which the PlayList refers to. 
[0459] In step S274, it lets a user interface pass and the marking point of a 
playback start point is specified as a control section 23 by the user. In step 
S275, a control section 23 judges whether it is the mark to which the mark 
chosen by the processing in step S274 is stored in PlayListMark. When it is 
judged that it is the mark which is not progressed and stored in step S276 
when the selected mark is judged to be the mark currently stored in 
PlayListMark in step S275, it progresses to step S278. 
[0460] In step S276, a control section 23 acquires PTS of a mark, and 
Playltemjd to which it belongs. In step S277, a control section 23 acquires 
STC-sequence-id of AV stream which Playltem which Playltemjd points out 
refers to. 

[0461] A control section 23 makes AV stream input into the AV decoder 27 in 
step S278 based on STC-sequence-id and PTS of a mark. Specifically, step 
S243 of the flow chart of drawing 132 and the same processing as S244 are 



performed using this STC-sequence-id and PTS of a marking point. In step 
S279, the playback section 3 starts a display from the picture of PTS of a 
marking point. 

[0462] As explained with reference to drawing 9 , when PlayList is reproduced, 
the mark currently stored in ClipMark of Clip which the PlayList refers to can 
be referred to. Therefore, when Real PlayList and two or more Virtual PlayList 
are referring one Clip, since those PlayList(s) can share ClipMark of the one 
Clip, they can manage the data of a mark efficiently. 

[0463] Temporarily, when what doubled PlayListMark and ClipMark only with 
PlayList is defined and Real PlayList and two or more Virtual PlayList are 
referring one Clip like the above-mentioned example, each PlayList will have 
the mark information of Clip of the same content, and the effectiveness of 
record of data is bad, without defining ClipMark as Clip. 
[0464] Drawing 135 is drawing showing example of another of the syntax of 
PlayListMark(). length shows the byte count from the cutting tool just behind 
this length field to the cutting tool of the last of PlayListMark(). 
number_of_PlayList_marks shows the number of entries of the mark currently 
stored in PlayListMark. 

[0465] mark_invalid_flag is a 1-bit flag, and when it is shown that this mark 
has effective information when the value of this is set to zero and the value of 
this is set to 1 , it is shown that this mark is invalid. 

[0466] You may make it the record regenerative apparatus 1 change the value 
of the mark_invalid_flag into 1, when a user does operation which eliminates 
the entry of one mark on a user interface instead of eliminating the entry of 
the mark from PlayListMark. 

[0467] mark_type has the semantics which shows the type of a mark and is 
shown in drawing 136 . mark_name_length shows the cutting tool length of 
the mark name shown in the Mark_name field. The value of this field is 32 or 
less. ref_to_PlaylternJd shows the value of Playltem_id which specifies 
Playltem on which the mark is put. The value of Playltemjd corresponding to 
a certain Playltem is defined in PlayList(). 

[0468] mark_time_stamp stores the time stump in which the point with which 
the mark was specified is shown. mark_time_stamp points out the time 



amount in the playback range pinpointed by IN_time defined in Playltem 
shown by ref_to_PlayltemJd, and OUTJime. The semantics of a time stump 
is the same as drawing 44 . 

[0469] When entry_ES_PID is set to OxFFFF, the mark is a pointer to a time- 
axis top common to all the elementary streams used by PlayList. When 
entry_ES_PID is set to the value which is not OxFFFF, entry_ES_PID shows 
the value of PID of transport Paquette containing the elementary stream to 
which it is pointed out by the mark. 

[0470] refJhumbnaiUndex shows the information on the thumbnail image 
added to a mark. The semantics is the same as ref_thumbnail_index of 
drawing 42 . mark_name shows the identifier of a mark. The byte count shown 
by mark_name_length from the left in this field is an effective character 
alphabetic character, and an identifier is shown. This character alphabetic 
character is encoded by the approach shown by character_set in 
UlApplnfoPlayList. 

[0471] As for the value of the cutting tool who follows these effective 
characters alphabetic character in the mark_name field, what kind of value 
may be in close. In the case of this syntax, a mark can point out a specific 
elementary stream. For example, while PlayList is referring to the multi-view 
program which has two or more video streams in a program, entry_ES_PID is 
used in order to set the video PID in which one video stream in the program is 
shown. 

[0472] PlayList to which a user refers to a multi-view program is reproduced, 
and the user presupposes that one view in a multi-view is seen. Suppose that 
the command was now sent so that a user might skip playback to the 
following marking point to the record regenerative apparatus 1. In this case, 
the mark of entryJES_PID which is the same value as the video PID of the 
view which the user is looking at now should be used for the record 
regenerative apparatus 1, and, as for the record regenerative apparatus 1, it 
should not change a view freely. The mark to which entry_ES_PID is set to 
OxFFFF may be used for the record regenerative apparatus 1 again. In this 
case, the record regenerative apparatus 1 does not change a view freely. 
[0473] Drawing 137 is drawing showing example of another of CiipMarkQ of 



syntax shown in drawing 81 . length shows the byte count from the cutting tool 
just behind this length field to the cutting tool of the last of ClipMarkQ. 
makerJD shows the manufacturer ID of the manufacturer who defines the 
markjype, when markjype shows the value of 0x7F from 0x60. 
[0474] number_of_Clip_marks shows the number of entries of the mark 
currently stored in ClipMark. mark_invalid_flag is a 1-bit flag, and when it is 
shown that this mark has effective information when the value of this is set to 
zero and the value of this is set to 1, it is shown that this mark is invalid. 
[0475] When a user does operation which eliminates the entry of one mark on 
a user interface, the value of the markjnvalidjlag may be made to be 
changed into 1 instead of a record machine eliminating the entry of the mark 
from ClipMark. markjype has the semantics which shows the type of a mark 
and is shown in drawing 138 . 

[0476] ref_to_STC_id shows STC-sequence-id which specifies STC-sequence 
on which both mark_time_stamp and representative_picture_time_stamp are 
put. The value of STC-sequence-id is defined in STCInfo(). mark_time_stamp 
is the same semantics as mark_time_stamp in the case of mark_entry() of 
drawing 81 . 

[0477] When entry_ES_PID is set to OxFFFF, the mark is a pointer to a time- 
axis top common to all the elementary streams in Clip. When entry JES_PID is 
set to the value which is not OxFFFF, entry_ES_PID shows the value of PID of 
transport Paquette containing the elementary stream to which it is pointed out 
by the mark. 

[0478] reMo_thumbnail_index shows the information on the thumbnail image 
added to a mark. The semantics is the same as ref_thumbnail_index of 
drawing 78 . representative_picture_time_stamp is the same semantics as 
mark_time_stamp in the case of representative_picture_entry() of drawing 81 . 
[0479] In the case of the syntax shown in drawing 137 , a mark can point out a 
specific elementary stream. For example, when Clip includes the multi-view 
program which has two or more video streams in a program, entry_ES_PID is 
used in order to set the video PID in which one video stream in the program is 
shown. 

[0480] PlayList to which a user refers to a multi-view program is reproduced, 



and the user presupposes that one view in a multi-view is seen. Suppose that 
the command was now sent so that a user might skip playback to the 
following marking point to the record regenerative apparatus 1. In this case, 
the mark of entry_ES_PlD which is the same value as the video PID of the 
view which the user is looking at now should be used for the record 
regenerative apparatus 1, and, as for the record regenerative apparatus 1, it 
should not change a view freely. The mark to which entry_ES_PID is set to 
OxFFFF may be used for the record regenerative apparatus 1 again. In this 
case, the record regenerative apparatus 1 does not change a view freely. 
[0481] The content of the data currently recorded on the record medium 100, 
playback information, etc. can be managed appropriately, and it has them, 
and a user can check the content of the data currently recorded on the record 
medium appropriately at the time of playback, or it can make it possible to 
reproduce desired data simple by being based on such syntax, DS, and a 
regulation. 

[0482] According to the database configuration of the gestalt of this operation, 
by edit etc., since it dissociates independently and a PlayList file and a Clip 
Information file are recorded, when predetermined PlayList and the content of 
Clip are changed, it is not necessary to change other files which are unrelated 
to the file. Therefore, time amount which can change the content of the file 
easily and the modification and record take can be made small. 
[0483] Moreover, only Info.dvr is read first, the content of record of a disk is 
shown to a user interface, and if only the PlayList file in which the user did 
playback directions, and the Clip Information file relevant to it are read from a 
disk, a user's latency time can be made small. 
[0484] Temporarily, if all PlayList files and Clip Information files are 
collectively recorded on one file, the file size will become very large. Therefore, 
the time amount which it takes in order to change the content of the file and to 
record it becomes very large compared with the case where dissociate 
independently and each file is recorded. By applying this invention, it 
becomes possible to prevent such a thing. 

[0485] As mentioned above, ClipMark which stores the mark indicating the 
characteristic image in AV stream file, i.e., a Clip AV stream file It records, the 



management information data file, i.e., the Clip Information file, of said AV 
stream. Moreover, an object with the information on one playback procedure 
defined with the combination of the section when it was specified in AV 
stream, That is, PlayListMark which stores the mark which shows the Resume 
point when reproducing the marking point specified by a user or its object out 
of the playback range of PlayList is recorded on an object. 
[0486] When PlayList is reproduced by doing in this way, the mark currently 
stored in ClipMark of Clip which the PlayList refers to can be referred to. 
Therefore, when Real PlayList and two or more Virtual PlayList are referring 
one Clip, since those PlayList(s) can share ClipMark of the one Clip, they can 
manage the data of a mark efficiently. 

[0487] Temporarily, when what doubled PlayListMark and ClipMark only with 
PlayList is defined and Real PlayList and two or more Virtual PlayList are 
referring one Clip like the above-mentioned example, each PlayList will have 
the mark information of Clip of the same content, and the effectiveness of 
record of data is bad, without defining ClipMark as Clip. By applying this 
invention, it becomes possible to prevent such a thing. 
[0488] As mentioned above, it is possible by file-izing ClipMark for storing 
EP_map for storing the address of an entry point, the type (for example, point 
of a program pulling out the head) of the picture of a marking point, and the 
address in AV stream of the picture as attached information on AV stream as 
Clip Information File, and recording it on a record medium 100 to manage 
appropriately the encoded information of a stream required for playback of a 
stream required for playback of AV stream. 

[0489] Using this Clip Information file information, a user can search the 
scene which is interested out of AV stream currently recorded on the record 
medium 100, for example, the point of a program pulling out the head etc., 
and the decision of the read-out location of AV stream from a record medium 
100 becomes easy to a user's random access or directions of special 
playback, and decode initiation of a stream can be performed promptly. 
[0490] Although a series of processings mentioned above can also be 
performed by hardware, they can also be performed with software. The record 
regenerative apparatus 1 is constituted by the personal computer as shown in 



drawing 139 in this case. 

[0491] In drawing 139 , CPU (Central Processing Unit)201 performs various 
kinds of processings according to the program memorized by ROM (Read 
Only Memory)202 or the program loaded to RAM (Random Access 
Memory)203 from the storage section 208. To RAM203, CPU201 performs 
various kinds of processings upwards again, and required data etc. are 
memorized suitably. 

[0492] CPU201, ROM202, and RAM203 are mutually connected through the 
bus 204. The input/output interface 205 is also connected to this bus 204 
again. 

[0493] The communications department 209 which consists of the storage 
section 208 which consists of a display which consists of the input section 206 
which consists of a keyboard, a mouse, etc., CRT, LCD, etc., the output 
section 207 which becomes a list from a loudspeaker etc., a hard disk, etc., a 
modem, a terminal adopter, etc. is connected to the input/output interface 205. 
The communications department 209 performs the communications 
processing through a network. 

[0494] Drive 210 is connected to an input/output interface 205 again if needed, 
it is suitably equipped with a magnetic disk 221, an optical disk 222, a 
magneto-optic disk 223, or semiconductor memory 224, and the computer 
program by which reading appearance was carried out from them is installed 
in the storage section 208 if needed. 

[0495] Although a series of processings mentioned above can also be 
performed by hardware, they can also be performed with software. When 
performing a series of processings with software, the program which 
constitutes the software is installed in a general-purpose personal computer 
etc. from a record medium possible [ performing various kinds of functions ] 
by installing the computer built into the hardware of dedication, or various 
kinds of programs. 

[0496] As shown in drawing 139 , this record medium is distributed apart from 
a computer in order to provide a user with a program. The magnetic disk 221 
(a floppy disk is included) with which the program is recorded, an optical disk 
222 (CD-ROM (Compact Disk-Read Only Memory) ~) DVD (Digital Versatile 



Disk) is included. It is not only constituted by the package media which consist 
of a magneto-optic disk 223 (MD (Mini-Disk) is included) or semiconductor 
memory 224, but It consists of hard disks with which ROM202 with which a 
user is provided in the condition of having been beforehand included in the 
computer, and the program is remembered to be, and the storage section 208 
are contained. 

[0497] In addition, in this description, even if the processing serially performed 
according to the sequence that the step which describes the program offered 
by the medium was indicated is not of course necessarily processed serially, it 
is a juxtaposition thing also including the processing performed according to 
an individual. 

[0498] Moreover, in this description, a system expresses the whole equipment 

constituted by two or more equipments. 

[0499] 

[Effect of the Invention] It sets to a program like the above at the 1st 
information processor of this invention and an approach, and a list. While 
generating ClipMark which consists of marks indicating the characteristic 
image extracted from inputted AV stream as management information for 
managing AV stream Out of the playback section corresponding to PlayList 
which defines the combination of the predetermined section in AV stream 
Since PlayListMark which consists of marks indicating the image specified as 
arbitration was generated, and a user uses ClipMark and PlayListMark as the 
table which became independent respectively and recorded them on the 
record medium It becomes possible to access the location of a request of AV 
stream promptly and certainly. 

[0500] In the 2nd information processor of this invention and an approach, 
and a list, moreover, a program The management information for managing 
AV stream containing ClipMark which consists of marks indicating the 
characteristic image extracted from AV stream, Out of the playback section 
corresponding to PlayList which defines the combination of the predetermined 
section in AV stream PlayListMark which consists of marks indicating the 
image which the user specified as arbitration is read. The management 
information by which reading appearance was carried out, and the information 



by PlayLisMark are shown. Since AV stream was reproduced from the 
location corresponding to ClipMark including ClipMark referred to from the 
shown information with reference to ClipMark corresponding to PlayList the 
user instructed playback to be It becomes possible to access the location of a 
request of AV stream promptly and certainly. 
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[Brief Description of the Drawings] 

[Drawing 1] It is drawing showing the configuration of the gestalt of 1 

operation of the record regenerative apparatus which applied this invention. 

[Drawing 2] It is drawing explaining a format of the data recorded on a record 

medium with the record regenerative apparatus 1 . 

[Drawing 3] It is drawing explaining Real PlayList and Virtual PlayList. 

[Drawing 4] It is drawing explaining creation of Real PlayList. 

[Drawing 5] It is drawing explaining deletion of Real PlayList. 

[Drawing 6] It is drawing explaining assemble editing. 

[Drawing 7] It is drawing explaining the case where subpass is prepared in 

Virtual PlayList. 

[Drawing 8] It is drawing explaining modification of the playback sequence of 
PlayList. 

[Drawing 9] It is drawing explaining the mark on PlayList, and the mark on Clip. 
[Drawing 10] It is drawing explaining a menu thumbnail. 
[Drawing 11] It is drawing explaining the mark added to PlayList. 
[Drawing 12] It is drawing explaining the mark added to a clip. 
[Drawing 13] It is drawing explaining the relation of PlayList, Clip, and a 
thumbnail file. 

[Drawing 14] It is drawing explaining directory structure. 
[Drawing 15] It is drawing showing the syntax of info.dvr. 
[Drawing 16] It is drawing showing the syntax of DVR volume. 



[Drawing 17] It is drawing showing the syntax of Resumevolume. 

[Drawing 18] It is drawing showing the syntax of UlApplnfovolume. 

[Drawing 19] It is drawing showing the table of Character set value. 

[Drawing 20] It is drawing showing the syntax of TableOfPlayList. 

[Drawing 21] It is drawing showing other syntax of TableOfPlayList. 

[Drawing 22] It is drawing showing the syntax of MakersPrivateData. 

[Drawing 23] It is drawing showing the syntax of xxxxx.rpls and yyyyy.vpls. 

[Drawing 24] It is drawing explaining PlayList. 

[Drawing 25] It is drawing showing the syntax of PlayList. 

[Drawing 26] It is drawing showing the table of PlayList_type. 

[Drawing 27] It is drawing showing the syntax of UlAppinfoPlayList. 

[Drawing 28] It is drawing explaining the flag in the syntax of 

UlAppinfoPlayList shown in drawing 27 . 

[Drawing 29] It is drawing explaining Playltem. 

[Drawing 30] It is drawing explaining Playltem. 

[Drawing 31] It is drawing explaining Playltem. 

[Drawing 32] It is drawing showing the syntax of Playltem. 

[Drawing 33] It is drawing explaining IN_time. 

[Drawing 34] It is drawing explaining OUTJime. 

[Drawing 35] It is drawing showing the table of Connection_Condition. 

[Drawing 36] It is drawing explaining Connection_Condition. 

[Drawing 37] It is drawing explaining BridgeSequencelnfo. 

[Drawing 38] It is drawing showing the syntax of BridgeSequencelnfo. 

[Drawing 39] It is drawing explaining SubPlayltem. 

[Drawing 40] It is drawing showing the syntax of SubPlayltem. 

[Drawing 41] It is drawing showing the table of SubPath_type. 

[Drawing 42] It is drawing showing the syntax of PlayListMark. 

[Drawing 43] It is drawing showing the table of Mark_type. 

[Drawing 44] It is drawing explaining Mark_time_stamp. 

[Drawing 45] It is drawing showing the syntax of zzzzz.clip. 

[Drawing 46] It is drawing showing the syntax of Cliplnfo. 

[Drawing 47] It is drawing showing the table of Clip_stream_type. 

[Drawing 48] It is drawing explaining offset_SPN. 
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EP_map_for_j 
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Drawing 80] 



t is drawing explaining offset_SPN. 
t is drawing explaining the STC section, 
t is drawing explaining STCJnfo. 
t is drawing showing the syntax of STCJnfo. 
t is drawing explaining Programlnfo. 
t is drawing showing the syntax of Programlnfo. 
t is drawing showing the syntax of VideoCondinglnfo. 
t is drawing showing the table of Video_format. 
t is drawing showing the table of frame_rate. 
t is drawing showing the table of display_aspect_ratio. 
t is drawing showing the syntax of AudioCondinglnfo. 
t is drawing showing the table of audio_coding. 
t is drawing showing the table of audio_component_type. 
t is drawing showing the table of sampling_frequency. 
t is drawing explaining CPI. 
t is drawing explaining CPI. 
t is drawing showing the syntax of CPI. 
t is drawing showing the table of CPLtype. 
t is drawing explaining video EP_map. 
s drawing explaining EP_map. 
s drawing explaining EP_map. 
s drawing showing the syntax of EP_map. 
s drawing showing the table of EP_type values, 
s drawing showing the syntax of 
one_strea m_P I D . 

s drawing explaining TLLmap. 
s drawing showing the syntax of TLLmap. 
s drawing showing the syntax of ClipMark. 
s drawing showing the table of mark_type. 
s drawing showing the table of mark_type_stamp. 
s drawing showing other examples of the syntax of ClipMark. 
t is drawing showing other examples of the table of Mark_type. 
t is drawing showing the example of mark_entry() and 



representative_picture_entry(). 

[Drawing 81] It is drawing showing the syntax of mark_entry() and 
representative_picture_entry(). 

[Drawing 82] It is drawing showing other examples of the syntax of 
mark_entry() and representative_picture_entry(). 

[Drawing 83] It is drawing explaining the relation between RSPN_ref_EP_start 
and offset_num__pictures. 

[Drawing 84] It is drawing showing other examples of the syntax of 
mark_entry() and representative_picture_entry(). 

[Drawing 85] It is drawing explaining the relation between ClipMark and 
EP_map. 

[Drawing 86] It is drawing showing the syntax of menu.thmb and mark.thmb. 
[Drawing 87] It is drawing showing the syntax of Thumbnail. 
[Drawing 88] It is drawing showing the table of thumbnail_picture_format. 
[Drawing 89] It is drawing explaining tn_block. 

[Drawing 90] It is drawing explaining the structure of the transport stream of 
DVR MPEG 2. 

[Drawing 91] It is drawing showing the recorder model of the transport stream 
of DVR MPEG 2. 

[Drawing 92] It is drawing showing the player model of the transport stream of 
DVR MPEG 2. 

[Drawing 93] It is drawing showing the syntax of source packet. 

[Drawing 94] It is drawing showing the syntax of TP_extra_header. 

[Drawing 95] It is drawing showing the table of copy permission indicator. 

[Drawing 96] It is drawing explaining seamless connection. 

[Drawing 97] It is drawing explaining seamless connection. 

[Drawing 98] It is drawing explaining seamless connection. 

[Drawing 99] It is drawing explaining seamless connection. 

[Drawing 100] It is drawing explaining seamless connection. 

[Drawing 101] It is drawing explaining the overlap of an audio. 

[Drawing 102] It is drawing explaining the seamless connection using 

BridgeSequence. 

[Drawing 103] It is drawing explaining the seamless connection which does 



not use BridgeSequence. 

[Drawing 104] It is drawing showing a DVR STD model. 
[Drawing 105] It is drawing showing the timing chart of decode and a display. 
[Drawing 106] It is a flow chart explaining the search playback of a scene 
shown with the marking point in the case of the syntax of drawing 81 . 
[Drawing 107] It is drawing explaining actuation of the playback in the case of 
the syntax of drawing 81 . 

[Drawing 108] It is drawing showing the example of EP_map. 

[Drawing 109] It is drawing showing the example of ClipMark. 

[Drawing 110] It is a flow chart explaining CM skip regeneration in the case of 

the syntax of drawing 81 . 

[Drawing 111] It is a flow chart explaining CM skip regeneration in the case of 
the syntax of drawing 81 . 

[Drawing 112] It is a flow chart explaining the search playback of a scene 
shown with the marking point in the case of the syntax of drawing 82 . 
[Drawing 113] It is drawing explaining the playback in the case of the syntax 
of drawing 82 . 

[Drawing 114] It is drawing showing the example of EP_map. 

[Drawing 115] It is drawing showing the example of ClipMark. 

[Drawing 116] It is a flow chart explaining CM skip playback in the case of the 

syntax of drawing 82 . 

[Drawing 117] It is a flow chart explaining CM skip playback in the case of the 
syntax of drawing 82 . 

[Drawing 118] It is a flow chart explaining the search playback of a scene 
shown with the marking point in the case of the syntax of drawing 84 . 
[Drawing 119] It is drawing explaining the playback in the case of the syntax 
of drawing 84 . 

[Drawing 120] It is drawing showing the example of EP_map. 

[Drawing 121] It is drawing showing the example of ClipMark. 

[Drawing 122] It is a flow chart explaining CM skip playback in the case of the 

syntax of drawing 84 . 

[Drawing 123] It is a flow chart explaining CM skip playback in the case of the 
syntax of drawing 84 . 



[Drawing 124] It is drawing showing an application format. 

[Drawing 125] It is drawing explaining the mark on PlayList, and the mark on 

Clip. 

[Drawing 126] It is drawing showing other examples of the syntax of ClipMark. 
[Drawing 127] It is drawing showing the example of further others of the 
syntax of ClipMark. 

[Drawing 128] It is a flow chart explaining creation of ClipMark in the case of 
encoding and recording an analog AV signal. 

[Drawing 129] It is a flow chart explaining creation of ClipMark in the case of 
recording a transport stream. 

[Drawing 130] It is a flow chart explaining creation of RealPlayList. 
[Drawing 131] It is a flow chart explaining creation of VirtualPlayList. 
[Drawing 132] It is a flow chart explaining playback of PlayList. 
[Drawing 133] It is a flow chart explaining creation of PlayListMark. 
[Drawing 134] It is a flow chart explaining the search playback at the time of 
reproducing PlayList. 

[Drawing 135] It is drawing showing the syntax of PlayListMark. 
[Drawing 136] It is drawing for explaining Mark_type of PlayListMark. 
[Drawing 137] It is drawing showing other syntax of ClipMark. 
[Drawing 138] It is drawing for explaining Mark_type of ClipMark. 
[Drawing 139] It is drawing explaining a medium. 
[Description of Notations] 

1 Record Regenerative Apparatus 11 thru/or 13 Terminal, 14 Analysis section 
15 AV encoder, 16 Multiplexer 17 A switch, 18 Multiplexing stream analysis 
section 19 sow spa KETTAIZA 20 The ECC coding section, 21 Modulation 
section 22 The write-in section, 23 Control section 24 A user interface and 25 
switch 26 Demultiplexer 27 AV decoder 28 Read-out section 29 Recovery 
section 30 ECC decode section 31 Sow spa KETTAIZA 32 33 Terminal 



